npm prune --production removes packages from devDependencies. Is there any way to it also delete project folders that I do not want in production, such as my "spec" testing folder?
According to the docs, npm prune is used to mantain node_modules clean of extraneous packages, with the added functionality of removing dev dependencies when switching to production, so no, it doesn't seem configurable to perform such a task.
You could define a custom script in your package.json that will delete the folders and invoke npm prune after.
Related
Seems like a fairly straightforward thing, but I can't find anything on the interwebs.
It appears that npm prune --production only descends into the current package's node_modules folder. However, it does not recurse down the node_modules tree to remove devDependencies recursively. The result is that my project is a bit smaller in size thanks to the removal of its direct devDependencies, but the devDependencies of the project remain transitively, leaving it unnecessarily large in real projects.
Behavior is identical from npm versions 6.4.1 through 6.14.4.
Ok, figured it out, with not much help from the npm documentation.
To install only dependencies (that is, production dependencies only) recursively, you need two perform two steps:
Call npm ci. That installs only dependencies among a project's transitive dependencies, but it also installs a project's direct devDependencies.
Call npm prune --production. That gets rid of the top-level project's devDependencies.
With these steps, you can immensely reduce the size of your projects, which is helpful when they are deployables that create, say, Docker images. If you make sure to include RUN npm ci && npm prune --production in your Dockerfiles, your final image will be much smaller than if you don't, thanks to a much smaller node_modules directory.
So I'm in the process of publishing a package to npm. It is basically just a simple module that lets users make Ajax calls and can be configured in a few ways.
I have read that it is a good idea to test the install locally and tried that. I have packed the package via the "npm pack" command, change into another directory and then tried installing the packge via "npm install path-to-file-that-was-just-created.tgz".
So far everything works, I have a node_modules folder, that contains my bundled code.
However, is also has installed all the dependencies that I have listed as devDependencies in the package.json of my actual module, even though the only the bundled file is needed and no other depenedencies are defined.
I have tried updating the npm-shrinkwrap.json, and checked that every dependency has the dev property marked as true.
The goal is actually for the user to install this module and then have no dependencies installed, because they do not need babel or mocha, to run the module.
How can I exclude these from the packge?
Thanks!
https://docs.npmjs.com/cli/install
use the --production flag to avoid installing dev dependencies
For published modules, you don't need to do anything, when a user installs your library, only the non-dev dependencies will be installed
If you want your published module to have no dependencies but you still need to have some to build it you can also try to use this command before publishing:
npx json -f package.json -I -e "delete this.devDependencies"
This way only works in CI/CD.
Update: it turned out that npm pkg delete devDependencies does the same without any additional dependency
After running your install, you can prune dev dependencies by running this command:
npm prune --production
this will keep only production dependencies. Documentation from npm here:
If the --production flag is specified or the NODE_ENV environment
variable is set to production, this command will remove the packages
specified in your devDependencies
I am learning Angular and each time it takes like 5 minutes to create a new project because of 100MB folder "node_modules" which CLI creates. And the files in this folder are always the same (unless you add some dependencies which I never do). Is there a way to use one node_modules folder for every project?
Have a look in to https://yarnpkg.com/blog/2017/08/02/introducing-workspaces/
Yarn Workspaces is a feature that allows users to install dependencies
from multiple package.json files in subfolders of a single root
package.json file, all in one go.
Making Workspaces native to Yarn enables faster, lighter installation
by preventing package duplication across Workspaces. Yarn can also
create symlinks between Workspaces that depend on each other, and will
ensure the consistency and correctness of all directories.
npm install -g yarn
You can install all dependencies globally or create a symlink from one place to every project.
BUT it is bad practice, correct way is to use separate node_modules for each project, even if you are using same packages. Once you will need use different versions of same package in different projects and common node_modules will cause a lot headache.
Try to use npm cache and npm install --prefer-offline if you just want to install package faster and don't care about version very match. I didn't use it but believe it should work.
Only packages installed by node (npm install) can be in the node_modules folder. This is because, if someone wants to install your project, instead of downloading the whole project with the node_modules included. They type npm install.
Based on the packag.json the node_modules will now be downloaded to the node_modules folder.
So you can put angular in the node_modules folder if it is an npm package. No you cannot put your own files in this folder.
So you can just copy your package.json to every project and run npm install. Then all the node_modules will be the same.
My node_modules has packages that are not listed in my package.json's dependencies, so I'm guessing that those packages are dependencies of my dependencies. How would I be able to check this? I want to make sure that there aren't any unnecessary packages in my node_modules directory.
If your dependency list won't take too long to reinstall, a simple option is a table-flip: remove the node_modules directory entirely and run npm install to re-create it.
If you don't want to do that, you can try tools that inspect your dependencies, like depcheck as #sagar-gopale suggests in their answer.
Related: Run npm -v to find out if you are running npm v2 or v3. Like #cartant says in their answer, with v3, your node_modules directory will be maximally flat, which means things that used to appear as subdirectories of other modules (when installed with npm v2) will now appear at the top level of node_modules itself. That may be the reason you see more modules than you expect.
If you are using NPM 3, you will likely see a large number of modules that you were not expecting to see in the node_modules directory, as NPM 3 flattens the dependency hierarchy.
Whichever version you are using, if you run the npm list command, NPM should highlight any extraneous modules that are not required.
Please checkout this package.
https://www.npmjs.com/package/depcheck
Since packages can require other packages, just because there are packages in the node_modules folder that don't exist in your packages.json file doesn't mean they aren't needed by one of your specified packages.
If you run an npm prune command on the root directory of your solution it will read the dependency tree and remove the packages that are truly no longer needed.
I'm working in a web application (JavaScript/C#, version controlled by TFS) and our team wants to start using Visual Studio 2015. Microsoft is moving developers to use existing popular tools like Gulp for automated tasks, so I've written a few Gulp tasks that will run on the server.
My problem is that our automated builds generate new project folders on the build server, so I can't run gulp myBuildTask without first running npm install. The npm install adds over 2 minutes to the build process, and it seems very inefficient to download the same dependencies for every build (since they will change rarely).
Is there anyway I can run a Gulp task on a new project folder without first running npm install?
Options I've considered:
Include node_modules in TFS. I couldn't add the node_modules folder to TFS (which would cause it to exist in each new build folder) because bower's nested dependencies have file paths that are too long for Windows. I could go this route without bower, but I'm not certain I want all those files in my solution (much of which is not needed, like readme's and test files).
Run npm install after each automated build.
As already mentioned, I don't want to do this because it adds several minutes to the build process.
Install NPM modules globally.
I'm not sure if this is even possible, but I'm wondering if I can install all project dependencies globally on the build server (avoiding having to install at the project level). My concern with an approach like this is that I don't want to have to manually update the build server's globally installed NPM modules every time we add a gulp plugin.
Ideally, the solution would be something like #3. The modules would install globally, but every build could run an npm install which would verify every module is installed. If a new npm module was added to the package.json, it would be downloaded. This npm install would be pretty fast since in most cases, all modules would already exist (globally installed on the build server).
There are a few things you might do:
Make npm install run faster. For this purpose, use newest npm (if possible) or use npm dedupe. Running dedupe may result in having less dependencies than with plain npm install. Then run npm shrinkwrap which creates npm-shrinkwrap.json file which contain 'freezed' info about what exactly gets installed (and in which version) during npm install.
Remember, node_modules is just a directory, if you can copy / rsync it to your installation, you can skip the npm install phase altogether
Node package resolution approach is to first try local node_modules directory and if not successful, (node_modules not there or dependency missing in node_modules) check out node_modules of the parent directory, then grandparent directory and so on. This means, you don't have to install packages globally, semi-global installation is quite sufficient
:
my_project
node_modules/
dependency1
dependency2
build_001/
build_002/
build_00x/
no node_modules here,
no deps here
Note however, that this, naturally, works only if your dependencies are really not changing. Since in real life you install something new from time to time, slightly enhanced approach might be helpful: organize your directories as follows:
my_project
ver_af729b
node_modules
build_001
build_002
ver_82b5f3
node_modules
build_003
build_004
af729b and 82b5f3 being (prefixes of) sha hashes of your npm-shrinkwrap.json file. If you then add new dependency, shrinkwrap file gets updated, build script creates new ver_something directory and executes npm install in it. Doing all this would naturally require extra work, but it should work great.
------------------ EDIT -------------------
If you are not trying to avoid npm install completely (you just want it to be quick) you can stick to the typical scenario: you checkout the sources always to the same directory, and let npm install re-use the old node_modules as much as possible.
If you want always to create a new directory for your build, you may still create a node_modules symlink to the older version of node_modules - also in this scenario, npm will reuse as much as possible from symlinked folder.