I see --save-dev mentioned in Gulp tutorials and from what I see, it adds npm functionality to a project's dependency.
But what does that mean exactly? Is that significant when the project gets moved from one machine to another?
Thank you for any clarification of --save-dev importance with Gulp.
In a npm package there 2 types of dependencies: the production ones and the development ones.
{
"dependencies": {
// .. a list of production dependencies
// i.e. angular or express
},
"devDependencies": {
// .. a list of dependencies strictly needed only in development mode
// i.e. gulp or grunt
}
}
You need the former to make the application run in production. The latter are used when in development mode, so everything around the build system, minification, etc...
Gulp, as a building system, is more a devDependency by nature, than a production dependency. This is why you often find in Gulp/Gulp plugins tutorials things are:
$ npm install --save-dev gulp
That --save-dev flag will put the installed dependency you're asking in the devDependencies bucket while using --save sets the dependency in the dependencies (production) one.
Related
I have installed react-app-rewired as dev dependency according to docs.
"devDependencies": {
//...
"react-app-rewired": "^2.1.8",
},
Now I'd like to make a production build. When I use
NODE_ENV=production yarn install
consequent yarn build says that react-app-rewired: not found (because it is in dev only).
Does yarn build implies production under the hood?
If so, why do I need all the dev dependencies to be installed to make a production build?
Should I get rid of NODE_ENV or move react-app-rewired to production then?
When making the production build (when you need to transform your code, generate built assets, etc.), you usually need to have the dev dependencies installed since the dev dependencies contain the build tools needed to transform/compile the code into production code. When running the actual production code that is built from running yarn build, then you'd only need to have the production dependencies installed.
So, before the app is actually built, you need to run yarn install without NODE_ENV=production. Once the app is built (i.e. once you've ran yarn build and you have all the code transformed, all artifacts generated, etc.), then you'd re-run yarn install but with production mode turned on (NODE_ENV=production yarn install) so yarn only installs the dependencies in the dependencies section of package.json (these are the dependencies that your transformed code would depend on, whereas the build tools like react-app-rewired are only needed at build-time).
Trying to install a dev dependency but one of its dependencies is lodash: 4.17.20. When Snyk does a scan of my dependencies, it marks this dependency as a high security vulnerability.
How can we have this dev dependency try to resolve a different version of lodash for a dev dependency and pass the Snyk test?
Was thinking that in the yarn.lock file, it somehow needs to resolve a higher version of lodash for this dev dependency, so I've referred to https://classic.yarnpkg.com/en/docs/selective-version-resolutions/
Doing something in my package.json like
"resolutions": {
"**/lodash": "^4.17.20"
}
Or
"resolutions": {
"<that dev dependency>/lodash": "^4.17.20"
}
Seems like it hasn't quite worked, and the Yarn.lock hasn't updated the lodash dependency for that dev dependency. Wanted to see if this was possible without updating the yarn.lock manually as I could see it being re-overwritten in the future. This is done in a Lerna monorepo.
Update from the Snyk team, they do not have monorepo support with Lerna as of 04/05/21
I am in the process of switching my monorepo (back) from yarn (with workspaces) to lerna/npm, because yarn is too slow and unstable. However, I made an surprising discovery. With the following trivial package.json:
{
"devDependencies": { "lerna": "^2.11.0" },
"dependencies": { "typescript": "^2.9.1" }
}
and an empty lerna.json (in other words, no packages at all), then when I run
$ lerna bootstrap
it does not install anything at all in any top-level node_modules directory. And if for some reason I have a node_modules directory with no .bin subdirectory, then lerna bootstrap fails to create or populate the .bin subdirectory.
Is lerna not designed to actually specify top-level packages which are to be installed (along with their binaries in .bin)? I do notice that if I try lerna add on a lerna monorepo with no packages, it complains that "lerna WARN No packages found in scope where tslint can be added."
I could not find anything related to this in the documentation. With yarn/workspaces, I was using the ability to install global (top-level) versions of things like TypeScript for use in my build scripts while maintaining control over the version installed.
From the Lerna docs:
You can add the root as a managed location (in the packages array of lerna.json) - if that's something you need. This would cause lerna to link root's dependencies to your packages' directories, run postinstall script along with the others, etc.
I have a weird set of "local" npm modules that use TypeScript and depend on each other similar to:
A -> B, C
B -> C
C -> D
I need to run npm install and get all of my TypeScript compiled in order or it won't be able to find things properly. I'm under the impression I should use prepublish scripts to handle the TypeScript compile but it doesn't seem to cascade the prepublish request for local dependencies.
How am I supposed to set up a bunch of local modules with prepublish scripts such that they all get resolved appropriately when running npm install?
Another way to word what I am asking: How do I maintain multiple, local node modules and modify them at the same time? The modules have varying dependencies on each other and it is extremely inconvenient to modify them in isolation.
TypeScript compile but it doesn't seem to cascade the prepublish request for local dependencies.
Indeed prepublish only runs install for dependencies. Your dependencies should already be built (with prepublish) before putting them on NPM and installing them.
I figured out how to do what I needed. After updating to npm 3.3.9 and TypeScript 1.6, I was able to use a postinstall script to build things on the fly. The prototype lives here: https://github.com/MrHen/TypeScriptNpm
But the important pieces are:
// In the module's package.json
"scripts": {
"build": "gulp npmbuild",
"postinstall": "npm run build"
},
And:
// In the server's package.json
"dependencies": {
"hen-doodad": "file:../modules/hen-doodad",
"hen-widget": "file:../modules/hen-widget"
}
And:
// In the gulpfile
gulp.task('npmbuild', function() {
gulp_util.log('Detecting appropriate starting directory...', process.env.INIT_CWD);
var out = process.env.INIT_CWD + '/app';
var build = [process.env.INIT_CWD + '/**/*.ts', 'typings/tsd.d.ts', '!' + process.env.INIT_CWD + '/node_modules/**/*'];
var typings = 'typings/tsd.d.ts';
// ... do typescript build using above paths
Feels like a bit of a hack but this worked more consistently than prepublish. To run the whole thing, do an npm install inside of the server folder.
The gulp task is optional. Presumably you could use tsc directly.
It should be noted that this is most certainly not how you should be packaging up npm modules. The reason I had to do this involved details from a pre-existing build system.
Pitfalls from doing it this way:
Does not fit the standard publishing patterns used by npm.
The built files only ever live inside of the server's node_modules which can be awkward depending on what else you do with them.
Running npm install twice will not grab latest changes. You need to either remove the installed modules or update the version number on the module.
Each module gets its own TypeScript build instead of building en masse. If you can just build everything all at once you should do that instead.
Requires TypeScript 1.6 or greater due to how they auto-detect typings files included inside of node_modules.
Assuming that you are using TypeScript 1.6+ which support node module resolution. As you are trying to keep all modules synced, I guess your project is just starting.
I think symlinks would do the job, but if you have more concerns, please let me know.
More specifically, you may either create symlinks manually or take the advantages of npm link.
cd /path-of-a-module
npm link # this will create a link as global module
cd /path-of-your-app
npm link your-module-name
Then you may just maintain these modules happily.
As for dependencies configuration in your package.json file, it could be a git repository. But you could probably left the compiled *.js and *.d.ts files there and everything would just work.
I'm building a grunt javascript project with grunt, and I have a package.json file that looks something like:
{
... name, author, etc here ...
"dependencies": {
"grunt-html":"0.2.1"
}
}
I can run npm install to install grunt-html and this works just fine. But when I add new dependencies, all developers on the team must know to run npm install again. Is there a way to automatically install any packages that have not yet been installed? Should I just run npm install always to ensure I'm up to date?
Yes npm install is the easiest way IMO. Getting everyone familiar with the other npm commands makes managing deps easier as well. Such as:
npm ls to list out the currently installed modules.
Or the --save flag ie, npm install grunt-html --save to install and insert the package and version into your package.json.
npm prune to remove modules not included in your package.json.
Other ways to manage dependencies are to commit the node_modules folder in your repository to avoid other devs from having to run npm install. Or for more complex projects consider using npm shrinkwrap to lock down dependencies to specific versions: npm shrinkwrap docs.
I have not tried grunt-install-dependencies (https://github.com/ahutchings/grunt-install-dependencies), but it seems this may fullfill your needs. Just add the command install-dependencies as first task within your custom definfed grunt tasts, e.g.
grunt.registerTask('build', [ 'install-dependencies', 'useminPrepare', ... ]);