This question already has answers here:
NPM installs dependencies in a wrong place
(2 answers)
Closed 7 years ago.
I am trying to spin up a node service on my mac. When I run npm install in the folder where my node service is, it is installing modules which are not mentioned in my package.json. There are extra modules which I am not expecting and some modules that I expect are missing. What could be the reason? How does the node modules folder get created. Does it use any global set up? I am a newbie to nodejs and any help will be appreciated.
Well, it has been introduced with npm3 (https://github.com/npm/npm/blob/master/CHANGELOG.md#v300-2015-06-25):
Flat, flat, flat!
Your dependencies will now be installed maximally flat. Insofar as is
possible, all of your dependencies, and their dependencies, and THEIR
dependencies will be installed in your project's node_modules folder
with no nesting. You'll only see modules nested underneath one another
when two (or more) modules have conflicting dependencies.
I believe this is something new that happened in the newest version of npm.
If I'm not mistaken, it's installing all the dependencies flat instead of nested inside of whichever module that needs it.
Related
This question already has answers here:
Override registry for installed packages in package-lock.json
(4 answers)
Closed 4 months ago.
I have a Vue 2.7 project with vuetify installed. First, I install dependencies using a custom local npm registry, which is a proxy to npm default, now the project is growing and I'm using git actions to deploy for a development server, or at least I'm trying to.
When GitHub actions try to npm install it uses package-lock.json with my registry configured, and of course can't find it, if I delete my package-lock.json or set package-lock to false before install, it returns a lot of warns and error since packages dependencies are outdated.(this happens even when I use specific versions on package.json)
My questions are.
How can I update the npm registry for all my package-lock.json tree of dependencies in order to maintain the right version for every one of them?
Is there any other solution?
See my answer on a related question:
Find/replace registry in package-lock
Delete node_modules
Verify npm install works
I can't figure out why project dependency babel-polifyll doesn't relate to its internal packages from the own node_modules root (they're present there actually). Instead, it trying to get some dependency packages from the same level as the common project node_modules scope...
I understand that this is not a bug in babel-polifyll, probably something happens in node/yarn environment for sure. Anyway, I can't spot what exactly wrong...
Error:
Babel-polifyll reqiure imports that links from external scope:
This is an NPM thing, it by default tries to install all packages at the root level, so dependencies can be shared between components. This way when you build your code, if you have three packages using same component, then you output file will only need to have one copy of the built sub-component in it. This keeps the file size down a lot.
NPM will put a dependancy as a child when two packages require different versions of a library and normally you would never notice when this happens, unless you go looking.
This is great when it works, which it does most of the time, but can be a bit of a pig to sort out when it goes wrong.
I just had a look and the latest version of core-js is v3.2.1, but babel-polyfil requires v2.6.5. So the quick fix might be to force install the older version.
npm i -D core-js#2.6.5
This might break something else, if that happens try doing
rm -rf node-modules package-lock.json
npm i
Hopefully that will the force what ever needs the newer version of core-is to install as a child dep and everything will then work for you.
When performing an npm install with different versions of NPM does the contents of a modules directory within node_modules differ in any way?
Potentially.
NPM v3 introduced a flatter directory structure for dependencies than previously used, largely because the v2 structure could break Windows file name length restrictions.
More details are here: https://docs.npmjs.com/how-npm-works/npm3
I'm not aware of anything changing other than this, however packages can change their structure between releases.
I'm going through a tutorial by Kent C. Dodds on building an open source library. So far I have used npm to install chai, commitizen, cz-conventional-changelog, mocha, and unique-random-array.
I'm not sure when but I just noticed that my node_modules file became very large. There are around 100 folders just in the root of the node_modules folder.
I have attached two screenshots of some of the node_modules.
I do remember running npm install sementaic-release-cli without the global flag for a split second before realizing my mistake and quickly exiting the command. Could that split second have installed all these modules? If this is a result of my mistake then is there any way I can fix it?
What version of npm are you using? As of version 3, npm installs all dependencies as flatly as possible. So even though you only installed a few modules, those modules have dependencies of their own, and npm installs them all next to each other whenever possible.
Commitizen author here. Previously we had a bunch of our dev dependencies as regular dependencies. The latest Commitizen version removes this. If you clean out your node modules, install the latest Commitizen version, then rerun npm install you should have fewer dependencies.
I'm introducing unit testing in my project and for this, I need to make myself a package.json file.
First question is, which unit testing suite are you using? I'm looking forward mocha which seem to be pretty much standard for Node.js projects.
Second question is: Is there any magical way of generating a package.json file? (for dependencies and versions)
Third question is: I've been testing a lot of npm packages while developing my project and now I'm stuck with a lot of probably unused packages. Is there any way to tell which one are useless? (I saw npm list installed which is useful though)
I am using Mocha.
npm init
npm ls will list "extraneous" next to ones that are not in your package.json. But, it sounds like you don't have a package.json yet.
Basically, your workflow is very backward. Here is how it is intended to work:
Start a new project with npm init. It has no dependencies.
Oh, I want to start using a package, say express? Add it to package.json under dependencies, then run npm install.
Oh, I want to start using a package for development, say mocha? Add it to package.json under devDependencies, then run npm install.
You seem to have some existing code with manually-installed packages (via npm install <packageName>), which is a mess. I suggest starting over and following the above workflow.
To answer the third question:
npm prune
will remove all installed modules that are no longer mentioned in your package.json.
And you should really have asked 3 separate questions.
I am also using Mocha. It has code coverage, BDD, TDD, runs in browser. It is pretty complete and also heavily maintained by I think one of the most brilliant javascript/node.js programmers named TJ.
It is almost impossible to guess which version(s) to use. Because npm does not know which version breaks which dependencies. You could probably install all dependencies using something like node-detective. Then you can just install them using npm.js from within javascript. Maybe I would like to tackle this in the future.
I would also probably delete all dependencies , next install needed dependencies back using step(2). But also disc-space is not such a big case anymore with the current HDs.
P.S: I think I also agree with Domenic
I am using vows. It's pretty good, but not perfect. I have found unit testing in node to often be challenging because of async callbacks to dbs & such, and have mostly been testing top level functionality.
Here's your magic: Managing Node.js Dependencies with Shrinkwrap.
The only way to know what packages you are using is to know. You can't generate this programmatically. My advice would be to remove packages aggressively, then retest all functionality - if it breaks, you'll know you need to reinstall one of your packages.
Answering your third question, you can use Sweeper to list unused dependencies, and them remove them from your package.json. Just npm install -g sweeper then on your project directory call sweeper on the command line.