I have a number of modules that use the same devDependencies and I would like to make those dependencies a module itself, or some other way to manage them centrally. Are there any established patterns for achieving this?
I've looked in to using npm scripts to install the dev dependencies in the parent module, however it does feel a bit hacky e.g.
module-x has a dev dependency on module-shared-dev-dependencies. module-shared-dev-dependencies has a postinstall script that changes the cwd to module-x and npm install --save-dev eslint prettier husky ... etc. It then copies over the relevant config info such as rc files. Modules like husky currently only have the config info in the package.json file itself, so that would need modified too.
There is also the potential to have a base module in the git that all other modules fork from, however, I'd rather stick to an npm module approach if possible.
Related
I am trying to get the current dependencies and devDependencies versions that are set in the package.json file so that when the MakeFile is run for a new user, it installs the versions listed there and not just the latest version. So for the example below, instead of just saying npm install #applitools/eyes-testcafe we would grab the version 1.16.1 from the package.json and interpolate it there in the MakeFile like ${eyes_version} or something like that.
Any idea on how to do this? Thanks!
package.json
"devDependencies": {
"#applitools/eyes-testcafe": "^1.16.1",
"testcafe": "^1.18.6",
"testcafe-reporter-xunit": "*"
}
MakeFile
install-testcafe: npm ffmpeg applitools testcafe
# Installs all dependencies necessary for testcafe and node to run.
npm:
npm install
# Installs the ffmpeg video recorder. This is recursive as sometimes it doesn't install automatically.
ffmpeg:
npm install #ffmpeg-installer/ffmpeg
# Installs the applitools dependency. This is recursive as sometimes it doesn't install automatically.
applitools:
npm install #applitools/eyes-testcafe
# Installs TestCafe globally. This is recursive as sometimes it doesn't install automatically.
testcafe:
sudo npm install -g testcafe
Since you are using jq,
jq '.devDependencies["#applitools/eyes-testcafe"]' package.json
Is it useful?
I question the validity/usefulness of using a Make wrapper around NPM. You're wrapping a build tool in a build tool. Why? I'm guessing to make it more familiar to developers coming from a C/Make ecosystem. But mixing Make and NPM like this confuses Node/NPM developers, and NPM scripts can run CLI commands just like Make does.
Is npm i really more complicated than make npm? Seems like this information is better off in a README, and Make developers should be educated on how to use NPM (e.g. you can run CLI commands from inside NPM scripts). Adding Make scripts isn't adding any value here, but YMMV, maybe this is particularly useful inside your org.
Also don't use sudo when running npm.
So i'm looking at requirejs. I can either install this package with npm install requirejs, or download it manually from the website. What's the difference? Are there tradeoffs to either one? Is npm install just a fancier way of manually installing? Thanks.
imagine you have 10 libraries in package.json, and you want to install all of them at once, you can just do "npm i" and it will take care of all, in just ~10sec. compare this with installing those 10 lib manually, it is indeed a good friend, to help you ease the process of downloading lib for you in no time.
Yes, npm install is just a fancier way to add package that help saving your precious time.
Base on the description here: npm install.
If the package has a package-lock, or an npm shrinkwrap file, or a yarn lock file, the installation of dependencies will be driven by that
Install the dependencies in the local node_modules folder.
In global mode (ie, with -g or --global appended to the command), it installs the current package context (ie, the current working directory) as a global package.
By default, npm install will install all modules listed as dependencies in package.json.
With the --production flag (or when the NODE_ENV environment variable is set to production), npm will not install modules listed in devDependencies. To install all modules listed in both dependencies and devDependencies when NODE_ENV environment variable is set to production, you can use --production=false.
Without a package manager like npm or yarn, it could take you a lot of time just for installing stuff. And while you are developing with node js, you'd have ton of things to install.
Every modern programming language has it's own package manager, so why you ever need to manually install them?
I am trying to stage dependencies from the NPM registry in a Nexus NPM proxy repository for any arbitrary JavaScript project. I can perform an npm install or yarn install which will cause all the dependencies to be staged, but I'd like to avoid that. The main reason is I want to avoid needing the necessary C/C++ libraries installed to compile the dependencies that are NodeJS C/C++ add-ons.
The only solution I can think of is by parsing the package-lock.json/yarn.lock file and running npm pack <dependency> for each dependency, which will cause npm to fetch the needed dependency and copy the tarball of the dependency to the current directory. I could then delete each downloaded tarball.
Is there a more elegant solution for either npm or yarn?
If you run npm install --ignore-scripts then the install scripts will be ignored and so any C/C++ files won't be built anymore.
Ok so I have an npm project at my work that a bunch of us are working on. It has dependencies on 'lodash' and 'jquery'.
I do an >npm install, and it pulls down my deps. Then I bundle it.
That creates a 'package-lock.json' on my system.
Now another developer adds a new dependency on 'moment'.
He does a >npm install -S moment.
That adds it to his package.json, and he checks that in. We don't check in the package-lock.json.
Now I do a 'git pull' and get the new package.json.
Now I do >npm install, BUT because I have my own package-lock.json, it doesnt install 'moment' for me. So now I have to:
>rm package-lock.json
>npm install
And now I have 'moment'. Seems like this package-lock.json isn't really helping my workflow. Could I get an explanation of how this should work for developers on a day-to-day basis, if we are all developing on a common npm module?
First, according to npm documentation:
This file is intended to be committed into source repositories
so you should commit your initial package-lock.json after you've done npm install.
Another developer pulls your changes, including the lockfile.
Then he does npm -S moment, which makes updates to both package.json and package-lock.json. The developer pushes a commit with these changes.
Now you pull his changes and do npm install. It should install moment for you . Furthermore, you both should now have exactly the same version of moment and it's dependencies installed - even if between his and your installs minor version of some dependency was incremented.
Merge conflicts
It all gets messy when both of you have installed new dependencies in parallel and then have a conflict on package-lock.json. This may be a huge file and quite a pain to merge manually. I haven't seen documented any official way of dealing with it. There is even an open issue in npm repo to provide solution to resolving conflicts.
One user shares his workaround workflow in the issue thread there, which basically means: override your local changes with package.json and package-lock.json pulled from master, then apply all your npm install -S and npm remove -S commands again. This seems to be a reasonable solution until the issue is resolved by npm.
When I use the npm install 6 month ago and install module it create new one folder under the node_modules, the folder with all files for this module, but now when I use it create multifile files for one module, how can I install a module to specific folder as before ?
I use webStrorm
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.
Yes, in npm 3 your dependencies will be installed maximally flat, so it's all about npm versions.
Try running npm -v to make sure of that.
Here's an article about that.