I'm developing a browser-side package, with several runtime dependencies and developing tools. As suggested, I install them using NPM as dependencies and devDependencies respectively.
Eventually, before I publish it, I always compile every source file and external dependencies into one minimized file.
When I try to install it in another project, however, I noticed that all "dependencies" packages are also installed. I assume it's a standard NPM behavior, yet these packages should not be needed, as I've already compressed them all into my own .min.js file.
Should I just move them all to "devDependencies"?
Related
I am trying to demystify this NPM behavior. I have a custom library which I create for an Angular Project. The library is copied directly to the Node modules directory in my Angular Folder to test any new functionalities that I add on whatever project is using it. However, I notice the older version of the library is being used by the project.
I wonder whether this is due to the NPM Cache.
So my question is, how does the NPM cache and Node_Modules folder work hand in hand?
I can't directly answer as to how the cache relates to node_modules, but I can say that your package-lock.json file is likely the culprit behind your outdated packages. Try running npm update. If that doesn't work, try deleting your package-lock.json file and running npm install.
If that also doesn't work, make sure you have the correct version specified for your library in your project's package.json file. latest will grab the latest release available, ^1.0.0 will grab the latest minor and patch releases, ~1.0.0 will grab only the latest patch releases, and 1.0.0 will only grab that exact version.
I'm working on 2 projects, one library project is the npm depencency of the others.
The library project is automatically published to local npm registry (nexus) by CI (Gitlab), so developers that are only working on 2nd project don't need to download library project (at least this is the welcomed solution).
However, after deleting node_modules/mylibrary and calling npm install, I've found out, that I've got... old version of the package. The library was correcly built and our nexus allows redeploy, and it works perfectly in Gitlab CI (the project gets always the actual version of library package) so it looks like something was cached locally somewhere else (not in project itself).
How to force npm to download the actual version of the package, purging local cache if necessary? Increasing the library version after each commit is not a viable solution (if it was, there would be never the concept of snapshots in maven).
This is more of a conceptual question.
In Package.JSON file we have devDependencies and Dependencies. I understand what each is for. But are these in place simply to make it clearer to other developers what the dev dependencies and the production dependencies are when we distribute our files? If we weren't distributing our files would it make a difference if we put the devDependencies in the dependencies section? In my mind it shouldn't because the package.json is just used for npm installation and when we run our app through a bundler such as webpack it will only bundle up the modules required for deployment. In fact if we are not distributing our files theoretically do we even need a package.JSON file (although I see why we would want one so that we can move files from one place to another easily and just reinstall modules at the other end).
I believe this is a unique question because it asks not just what is the difference between dev and normal deps, but theoretically, is there are difference between the two if you don't publish. Allegedly duplicate answer does not talk about that, yet it's important for people's proper understanding of npm.
Back on your questions:
But are these in place simply to make it clearer to other developers what the dev dependencies and the production dependencies are when we distribute our files?
No. NPM will behave differently depending is it dev or "normal" dep. See more on alleged duplicate's accepted answer. For example, when you install published package, install doesn't install dev dependencies unless you explicitly request via a flag.
If we weren't distributing our files would it make a difference if we put the devDependencies in the dependencies section?
No difference functionality wise only if you don't publish. Besides being a bad practice, difficult to maintain and so on, of course.
Lets say I am working on a library that will be consumed by other developers. MyPackage has a dependency on moment. The developer that consumes my package also has a dependency on moment. So moment will exist as a "dependency" in both library package.json and application package.json (and thus get packaged twice). Is there a way to package it just once? If the consumer has it, use theirs, else use mine?
It's already happening by default on fresh installs if dependency ranges match.
npm v>=3 does gang the dependencies, depending on the installation order and depth, see here.
Also, if you kept working on the same folder for a while, there might be some cruft, which could be wiped using npm dedupe, see here.
In theory, moment should not be duplicated if both your library and developer's library are consuming the same version ranges of it. At least if npm dedupe is called or node_modules are wiped and npm i-nstalled.
I'm in environment with blocked access to github, typing and I want to have enhanced intellisense in vscode.
To do so I suppose I need to copy cached typescript definitions from machine that does have it for various needed npm packages.
So question where I can find those cached ata ts files?
Please consider an alternative, but here are the standard locations:
Mac: ~/Library/Caches/TypeScript
Windows: %LOCALAPPDATA%\Microsoft\TypeScript
Linux: ~/.cache/typescript/
As a better solution, if you cannot rely on automatic typings acquisition, you can manually manage type typings files. Here's some documentation information. For example:
$ npm install --save #types/express
This will download a copy of the express typings files to the normal node_modules folder your project. If you can't use npm, this is a much better place to copy files between.
Typings files are required to builds TypeScript projects, but are only used to enhance VSCode IntelliSense with JavaScript projects.
Hope that clears things up.