this is question is basically a variant of dependencies vs. devDependencies, I am looking through some source code these days, most of monorepo project will have a eslint-config to do lint
what confuses me is that they all put the eslint-plugin into dependencies not devDependencies
for example, a eslint config package called eslint-config, here's package.json
"dependencies": {
"#typescript-eslint/eslint-plugin": "^5.15.0",
"#typescript-eslint/parser": "^5.15.0",
"eslint-config-standard": "17.0.0-1",
"eslint-plugin-eslint-comments": "^3.2.0",
"eslint-plugin-html": "^6.2.0",
"eslint-plugin-import": "^2.25.4",
"eslint-plugin-jsonc": "^2.2.1",
"eslint-plugin-n": "^15.0.1",
"eslint-plugin-promise": "^6.0.0",
"eslint-plugin-unicorn": "^41.0.1",
"eslint-plugin-vue": "^8.5.0",
"eslint-plugin-yml": "^0.14.0",
"jsonc-eslint-parser": "^2.1.0",
"yaml-eslint-parser": "^0.5.0"
},
"devDependencies": {
"eslint": "^8.11.0"
},
we of course use it by npm i eslint-config -D, so I wonder if the eslint config get removed after bundled(I think it's 100% get removed), but I want to know the behand philosophy
According to the npm and yarn documentation, in addition to another answer with a similar question, devDependencies do not impact the bundle size as they are utilized in development mode.
Two related GitHub issue comments discuss the reasoning behind your question, specifically dependencies included at runtime:
https://github.com/facebook/create-react-app/issues/3209#issuecomment-336602578
https://github.com/typescript-eslint/typescript-eslint/issues/770#issuecomment-516056543
Related
I am using Gatsby Plugin sharp with other plugins for remark images. Package json provided below.
Strangely the build goes through fine on MacOS but fails inside the Debian docker container while try to fetch metadata for a PNG image. This error is faced by gatsby-plugin-sharp
package.json - only dependencies included
"dependencies": {
"#buzz/as-components": "^1.0.3",
"#dx/continuum-footer": "^1.5.1",
"#marcom/ac-sasskit": "^7.3.0",
"gatsby": "^2.26.1",
"gatsby-plugin-emotion": "^5.2.0",
"gatsby-plugin-flexsearch": "^1.0.3",
"gatsby-plugin-manifest": "^2.6.1",
"gatsby-plugin-offline": "^3.4.0",
"gatsby-plugin-react-helmet": "^3.4.0",
"gatsby-plugin-sass": "^3.0.0",
"gatsby-plugin-sharp": "^2.14.1",
"gatsby-remark-autolink-headers": "^2.10.0",
"gatsby-remark-code-buttons": "^2.0.4",
"gatsby-remark-images-anywhere": "^1.3.0",
"gatsby-remark-prismjs": "^3.13.0",
"gatsby-source-filesystem": "^2.5.0",
"gatsby-transformer-remark": "^2.16.0",
"gatsby-transformer-sharp": "^2.12.0",
"prismjs": "^1.23.0",
"prop-types": "^15.7.2",
"react": "^16.13.1",
"react-dom": "^16.12.0",
"react-helmet": "^6.1.0",
"react-multilevel-sidebar": "^1.0.4",
"remark-grid-tables": "^2.1.1",
"sass": "^1.32.4"
},
"engines": {
"node": ">=15.0.0 <=15.8.0"
},
"devDependencies": {
"node-sass": "^5.0.0",
"prettier": "2.2.1"
}
Error that I face:
/app/src/blog/2019-02-19-gridsome-05/plugins.png
Error: Input file contains unsupported image format
There isn't much details available around the error - Any help would be appreciated. I feel like this could be a C library issue as Gatsby Plugin builds on the fly and leverages C/CPP libraries.
Ended up solving this - Leaving the cause of issue here so that it can help others -
I was using a NodeJS - 15.8.0-slim base image. Gatsby Plugin Sharp is dependent on C libraries and binaries behind the scenes which were not really included in the Slim base image. I used 15.8.0-buster image and it worked all good.
The log was extremely misleading and ended up wasting a lot of my time. Hope this saves the time of anyone else who ends up with this.
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' }
]
});
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.
noob question regarding Node and npm: I have a package.json file with a list of dependancies that I want to install with npm install. When I run the command, nothing happens, I don't even receive an error, nothing at all :(
But if I try to install a single package from the list, it works perfectly...
I haven't created the package.json myself, so I am not sure what the "proxyURL" thing does...
{
"name": "dss",
"version": "0.0.0",
"repository": {
"type": "git",
"url": "*urlofmyrepo*"
},
"dependencies": {
"bower": "^1.7.7",
"cssmin": "^0.4.3",
"gulp": "^3.9.0",
"gulp-batch": "^1.0.5",
"gulp-concat": "^2.6.0",
"gulp-if": "^2.0.0",
"gulp-jshint": "^2.0.0",
"gulp-rename": "^1.2.2",
"gulp-sass": "^2.2.0",
"gulp-sourcemaps": "^1.6.0",
"gulp-strip-debug": "^1.1.0",
"gulp-uglify": "^1.5.1",
"gulp-util": "^3.0.7",
"gulp-watch": "^4.3.5",
"jshint": "^2.9.1",
"lodash": "^4.2.1",
"minimatch": "^3.0.0",
"sass": "^0.5.0",
"uglifyjs": "^2.4.10",
"underscore": "^1.8.3",
"yuglify": "^0.1.4"
},
"private": true,
"APIMethod": "stub",
"proxyURL": "http://localhost:8000",
"devDependencies": {}
}
Any clue?
Thank you
Rename/remove your package.json file.
Create a new package file by running:
npm init
Option A: Copy the dependencies you need into the newly created package.json.
Option B: Install the packages and use --save to add the packages to the package.json file.
Run npm install to install the dependencies.
just ran into this.
in my case the answer was environment variable NODE_ENV was set to 'production'
I haven't looked it up but when I changed it to something else, it started working.
I was testing this environment variable for something else and didn't realize it had this effect also.
For me it was a bad version value. Changing from 3.0 to 3.0.0 results in proper installation. 3.0 generates a warning, but fails to do the installation (ie it should be an error).