So I have an application that pulls in some dependencies. I have figured out how to lock those down quite easily and thus my Package.json looks like so:
"webpack": "2.2.1",
Great! So webpack is locked to that version, but I have noticed something in webpacks package.json. They don't lockdown their dependencies:
"dependencies": {
"acorn": "^4.0.4",
"acorn-dynamic-import": "^2.0.0",
"ajv": "^4.7.0",
"ajv-keywords": "^1.1.1",
"async": "^2.1.2",
"enhanced-resolve": "^3.0.0",
"interpret": "^1.0.0",
"json-loader": "^0.5.4",
"loader-runner": "^2.3.0",
"loader-utils": "^0.2.16",
"memory-fs": "~0.4.1",
"mkdirp": "~0.5.0",
"node-libs-browser": "^2.0.0",
"source-map": "^0.5.3",
"supports-color": "^3.1.0",
"tapable": "~0.2.5",
"uglify-js": "^2.8.5",
"watchpack": "^1.2.0",
"webpack-sources": "^0.2.0",
"yargs": "^6.0.0"
},
So the other day our app spun up on a container and grabbed webpack 2.2.1 like it should have, but grabbed the latest uglify-js which caused issues with our production app.
Is there anyway to enforce versions for dependencies that our dependencies are utilizing?
npm shrinkwrap is what I was looking for and needing.
Related
When I run
npm install cypress --save-dev
In a Windows CMD Administrator session, I get the following output. This has been left overnight and still hangs on 0%:
If it's important, my current project dependencies are
"devDependencies": { "#types/react": "^17.0.0", "#types/react-dom": "^17.0.0", "#types/webpack": "^4.41.25", "#types/react-router-dom": "^5.1.7", "#types/mui-datatables": "^3.7.3", "#types/react-text-mask": "^5.4.7", "#typescript-eslint/eslint-plugin": "^4.17.0", "#typescript-eslint/parser": "^4.17.0", "clean-webpack-plugin": "^3.0.0", "css-loader": "^5.0.1", "eslint": "^7.21.0", "eslint-config-prettier": "^8.1.0", "eslint-plugin-react": "^7.22.0", "eslint-plugin-react-hooks": "^4.2.0", "eslint-webpack-plugin": "^2.5.2", "html-webpack-plugin": "^4.5.0", "husky": "^4.3.8", "lint-staged": "^10.5.4", "prettier": "2.2.1", "style-loader": "^2.0.0", "ts-loader": "^8.0.11", "typescript": "^4.1.2", "url-loader": "^4.1.1", "webpack": "^5.9.0", "webpack-cli": "^4.2.0", "webpack-dev-server": "^3.11.0", "webpack-merge": "^5.4.0" },
"dependencies": { "#date-io/dayjs": "^1.3.13", "#fontsource/roboto": "^4.2.2", "#material-ui/core": "^4.11.2", "#material-ui/icons": "^4.11.2", "#material-ui/lab": "^4.0.0-alpha.57", "#material-ui/pickers": "^3.3.10", "axios": "^0.21.1", "clsx": "^1.1.1", "dayjs": "^1.10.4", "emailjs-com": "^3.1.0", "jwt-decode": "^3.1.2", "moment-timezone": "^0.5.33", "mui-datatables": "^3.7.7", "notistack": "^1.0.9", "react": "^17.0.1", "react-dom": "^17.0.1", "react-live-clock": "^5.2.0", "react-moment": "^1.1.1", "react-print-components": "^1.0.4", "react-router-dom": "^5.2.0", "react-text-mask": "^5.4.3", "text-mask-addons": "^3.8.0" }
Any help to identify the cause or any logs I should be looking at would be greatly appreciated
I had the same issue when trying do a fresh npm installation for a project.
Running in the same command in an elevated window did not help.
Jakob's answer helped above:
Visit https://docs.cypress.io/guides/getting-started/installing-cypress#Direct-download
Download the version of Cypress from https://download.cypress.io/desktop
or alternatively put the version number at the end : https://download.cypress.io/desktop/8.7.0
Extract the folder to:
C:\Users\[username]\AppData\Local\Cypress\Cache\[version]
I ran npm install and the install completed without error.
Unzipping manually downloaded cypress to AppData/Local/Cypress/Cache/[version]/ fixed the issue for me.
After removing cypress from the AppData/Local and AppData/Roaming if you try to run npx cypress open you will see:
Cypress executable not found at: C:\Users\[user]\AppData\Local\Cypress\Cache\8.5.0\Cypress\Cypress.exe
So it worked after unzipping Cypress there manually.
I had this same issue and seemed to fix this issue by upgrading to the latest version of node and npm.
It seems like an issue that happened to me when I had a power outage during installation - so if I am right it occurs when an installation is forced down midway. I managed to solve it by deleting every cypress folder from AppData before running npm install cypress --save-dev .
So I'm working on some projects within my work space and I notice that a lot of my dependencies are roughly 3 years old, including React itself. The thing I'm worried about is that if I run npm install or npm update that things might break and I could run into a plethora of issues. In my scenario I would like to know if it is better for me to do an npm install, npm update, or just leave it the way it is? (which I'm sure no one would recommend).
Here is our package.json file
{
"name": "my-app",
"version": "0.0.2",
"main": "index.js",
"license": "MIT",
"scripts": {
"start": "node src/entry",
"start-dev": "npm-run-all --parallel build babel-node",
"serve": "live-server public/",
"build-linux": "clear && webpack && clear && yarn build-server && clear && yarn start",
"build-windows": "cls && webpack && cls && yarn build-server && cls && yarn start",
"build-server": "babel src/server -d src",
"dev-server": "webpack-dev-server",
"babel-node": "nodemon --exec babel-node src/server.js"
},
"dependencies": {
"aws-sdk": "^2.358.0",
"axios": "^0.19.0",
"babel-cli": "^6.26.0",
"babel-core": "^6.26.3",
"babel-loader": "7.1.1",
"babel-plugin-transform-class-properties": "6.24.1",
"babel-polyfill": "^6.26.0",
"babel-preset-env": "^1.7.0",
"babel-preset-react": "6.24.1",
"babel-preset-stage-0": "^6.24.1",
"bcryptjs": "^2.4.3",
"body-parser": "^1.18.2",
"core-js": "^2.5.3",
"css-loader": "0.28.4",
"express": "latest",
"file-loader": "^1.1.5",
"fs": "0.0.1-security",
"google-maps-react": "^1.1.4",
"html2canvas": "^1.0.0-rc.3",
"image-webpack-loader": "^4.6.0",
"immutability-helper": "^2.4.0",
"jquery": "^3.4.1",
"jsonwebtoken": "^8.1.0",
"jspdf": "^1.5.3",
"lodash": "^4.17.14",
"moment": "^2.22.2",
"node-sass": "^4.11.0",
"nodemailer": "^4.7.0",
"normalize.css": "7.0.0",
"npm": "^6.10.1",
"promise-mysql": "^3.1.0",
"prop-types": "^15.6.0",
"react": "^16.0.0",
"react-csv": "^1.0.14",
"react-dom": "^16.0.0",
"react-router-dom": "4.2.2",
"react-scripts": "^2.1.3",
"sass-loader": "6.0.6",
"socket.io": "^2.0.3",
"style-loader": "0.18.2",
"table2csv": "^1.1.1",
"twilio": "^3.24.0",
"validator": "8.0.0",
"webpack": "^3.12.0",
"webpack-dev-middleware": "^3.5.0",
"webpack-dev-server": "^3.1.14"
},
"devDependencies": {
"concurrently": "^3.5.0",
"npm-run-all": "^4.1.1"
}
}
I already tried updating my react and react-dom versions to the latest, but I started getting warnings about componentWillMount and componentWillReceiveProps being outdated. I tried updating react-router-dom to get rid of some of those warnings, considering they were pointing to things like Link, Route, Switch, but that did not suppress them.
If anyone knows what the best way for me to go about this would be, and what the effects of npm install vs npm update would do to my system that would be great. I know what each of them is capable of doing, but I'm just trying to be cautious and want to know which one would be better in my scenario. Thanks.
When you run npm install on a project, npm installs latest versions satisfying the semantic versioning ranges defined in your package.json. After initial install, re-running npm install does not update existing packages since npm already finds satisfying versions installed on the file system.
When you run npm update it freshen already installed packages. When you run npm update, npm checks if there exist newer versions in the repository that satisfy specified semantic versioning ranges and installs them.
I would say "bite the bullet" and update them to latest. It will be a tedious task but if you are looking to maintain this for longer run, it is your best bet.
Updating stuff can break things or some dependencies will be deprecated after an update. I would not update anything unless it is necessary.
I have this new Ember project and I installed the google node sdk via npm install googleapis --save-dev. I then installed ember-cli-es6-transform in hopes of importing the es6 modules from the google api node client.
However I noticed in ./node_modules/googleapis there is a build/src folder instead of a src folder. In the Github repo, it's just a src folder. Why is this? This is causing my imports to be wonky while using ember-cli-es6-transform.
This is all that is in my devDependencies:
"devDependencies": {
"broccoli-asset-rev": "^2.4.5",
"ember-ajax": "^3.0.0",
"ember-cli": "~3.1.4",
"ember-cli-app-version": "^3.0.0",
"ember-cli-babel": "^6.6.0",
"ember-cli-dependency-checker": "^2.0.0",
"ember-cli-es6-transform": "^1.0.0",
"ember-cli-eslint": "^4.2.1",
"ember-cli-htmlbars": "^2.0.1",
"ember-cli-htmlbars-inline-precompile": "^1.0.0",
"ember-cli-inject-live-reload": "^1.4.1",
"ember-cli-qunit": "^4.1.1",
"ember-cli-sass": "^10.0.1",
"ember-cli-shims": "^1.2.0",
"ember-cli-sri": "^2.1.0",
"ember-cli-uglify": "^2.0.0",
"ember-data": "~3.1.0",
"ember-export-application-global": "^2.0.0",
"ember-load-initializers": "^1.0.0",
"ember-maybe-import-regenerator": "^0.1.6",
"ember-resolver": "^4.0.0",
"ember-source": "~3.1.0",
"ember-welcome-page": "^3.0.0",
"eslint-plugin-ember": "^5.0.0",
"googleapis": "^40.0.1",
"loader.js": "^4.2.3",
"sass": "^1.22.2"
},
npm does not require that a repository place its main file in any particular place or name it index.js. It is recommended that you look at a repo's package.json and use the path and file listed under the "main" key.
You can see it at https://github.com/googleapis/google-api-nodejs-client/blob/cb9326b902d6c203c498a2e269f256bcc3b23c2d/package.json#L42
googleapis chooses to build its source prior to putting it on npm to make it easier for us to use, hence the build/src directory.
For more information regarding the "main" key in package.json, see https://docs.npmjs.com/files/package.json#main
Note that ember-cli-es6-transform allows you to specify any path, so just put the correct path in as an argument.
app.import('node_modules/googleapis/build/src/index.js', {
using: [
{ transformation: 'es6', as: 'googleapis' }
]
});
I'm having a difficult time building a TypeScript application on Heroku.
My dependencies list includes a type definition for all of the packages I'm using:
"dependencies": {
"#nestjs/common": "^4.5.1",
"#nestjs/core": "^4.5.1",
"#nestjs/microservices": "^4.5.1",
"#nestjs/testing": "^4.5.1",
"#nestjs/websockets": "^4.5.1",
"#types/express": "^4.0.39",
"#types/jest": "^21.1.8",
"#types/json-schema": "^6.0.0",
"#types/jsonwebtoken": "^7.2.5",
"#types/mongoose": "^4.7.29",
"#types/node": "^8.5.1",
"#types/passport": "^0.4.2",
"#types/passport-jwt": "^3.0.0",
"#types/supertest": "^2.0.4",
"chalk": "^2.3.0",
"dotenv": "^4.0.0",
"express-jwt": "^5.3.0",
"global": "^4.3.2",
"jsonwebtoken": "^8.1.0",
"mongoose": "^4.13.7",
"passport": "^0.4.0",
"passport-jwt": "^3.0.1",
"redis": "^2.8.0",
"reflect-metadata": "^0.1.10",
"rxjs": "^5.5.5",
"tslint": "^5.8.0",
"ts-node": "^4.0.2",
"typescript": "^2.6.2"
},
However, when building on Heroku, I get:
error TS2688: Cannot find type definition file for 'node'
error TS2307: Cannot find module 'http'
and more. My tsconfig.json sets the typeRoots as './node_modules/#types' and I get a successful build locally.
Why can't Heroku find these types?
Apparently Heroku wasn't picking up changes to my package.json file or had cached some portion of the build process that was excluding #type definitions that I had moved from devDependencies to dependencies.
I cleared the build cache as such:
$ heroku plugins:install heroku-repo
$ heroku repo:purge_cache -a [appname]
$ git commit --allow-empty -m "Purge cache"
$ git push heroku master
and everything works as expected.
I am working on a Rails project that uses flexicious-react-datagrid and flexicious-react-datagrid-styles node modules. These modules are referenced in the package.json as:
"dependencies": {
...
"flexicious-react-datagrid": "file:./npm_libs/flexicious-react-datagrid",
"flexicious-react-datagrid-styles": "^1.2.0",
...
}
The problem I have is manually updating one of the modules to a licensed version.
The public flexicious-react-datagrid module is a trial version, which after some amount of time working with it, it has now expired and gives a popup with ErrorCode103 when trying to load the page and some infinite loop runs so the page becomes stuck loading forever.
The Flexicious team provides the licensed version by providing a react-datagrid.min.js file that contains the licensed code. Even though I replace this in the node module, The error still occurs.
This makes it seem like it's caching the old code server-side, since the code that would invoke the ErrorCode103 popup should be from the code that was replaced. I've tried loading in incognito or other browsers with no luck.
Our project uses browserify, and I have some suspicion (but not sure) that this may be what is caching the module. I haven't had any luck trying to find what is causing this issue so far.
My package.json:
{
"name": "redacted",
"version": "0.0.1",
"description": "redacted",
"author": "redacted",
"license": "SEE LICENSE IN LICENSE.TXT",
"babel": {
"comments": false,
"presets": [
"es2015",
"react"
]
},
"devDependencies": {
"browserify": "~> 14.0.0",
"browserify-incremental": "^3.1.0",
"browserify-css": "0.10.0"
},
"dependencies": {
"babel-core": "^6.0.0",
"babel-eslint": "^6.0.4",
"babel-loader": "^6.0.0",
"babel-polyfill": "^6.3.14",
"babel-preset-es2015": "^6.0.15",
"babel-preset-react": "^6.0.15",
"babelify": "^7.2.0",
"bower-webpack-plugin": "^0.1.9",
"codemirror": "^5.22.0",
"copy-webpack-plugin": "^4.0.1",
"copyfiles": "^0.2.1",
"core-js": "^2.4.0",
"css-loader": "^0.23.0",
"eslint": "^2.0.0",
"eslint-loader": "^1.0.0",
"eslint-plugin-react": "^5.1.1",
"file-loader": "^0.8.4",
"flexicious-react-datagrid": "file:./npm_libs/flexicious-react-datagrid",
"flexicious-react-datagrid-styles": "^1.2.0",
"gh-pages-deploy": "^0.4.0",
"glob": "^7.0.0",
"history": "^2.1.1",
"isparta-instrumenter-loader": "^1.0.0",
"jquery-browserify": "*",
"material-ui": "^0.16.5",
"minimist": "^1.2.0",
"mocha": "^2.2.5",
"moment": "^2.17.1",
"node-sass": "^3.4.2",
"normalize.css": "^4.1.1",
"null-loader": "^0.1.1",
"open": "0.0.5",
"postcss": "^5.0.11",
"postcss-loader": "^0.9.1",
"react": "^15.4.0",
"react-addons-test-utils": "^15.4.0",
"react-codemirror": "^0.3.0",
"react-day-picker": "^5.0.0",
"react-dom": "^15.4.0",
"react-router": "^2.4.0",
"react-tap-event-plugin": "^2.0.0",
"recursive-readdir-sync": "^1.0.6",
"rimraf": "^2.4.3",
"sass-loader": "^3.1.2",
"style-loader": "^0.13.0",
"url-loader": "^0.5.6"
}
}
flexicious-react-datagrid was version 1.1.6, it installs 1.3.8 which is the version I have my licensed code in within ./npm_libs/flexicious-react-datagrid.
Even not using the licensed code, 1.3.8 isn't being loaded as it is still giving me an error of an expired trial.
It was Browserify after all. I finally stumbled upon the cached version, it was hiding in a /tmp/ folder in the project's root directory.
I likely also blinded myself by having the Gitignored package in Sublime installed, which didn't show or search files/folders that were in the .gitignore file. I had to remove that package and edit my "folder_exclude_patterns" in my sublime-settings to re-show these folders.
I've included removing the tmp folder in its entirety to part of our build procedure so we don't have this issue again.
Yep, it looks as if you're still using a previously installed version of flexicious-react-datagrid.
The first guess is that you need to run npm install ./npm_libs/flexicious-react-datagrid to update this module. npm manager usually copies all dependency modules into node_modules dir and then node.js uses it to resolve require('flexicious-react-datagrid').