As I understand, the engines object is only for cases where someone installs my application. I would like to have something similar where I can prevent compiling errors on employee systems (because of wrong node versions etc.) before they happen.
I found that there are two packages:
https://github.com/jgillich/npm-check-engines/blob/master/index.js
https://github.com/kruppel/check-engines
But they are not working or not doing what I want.
It would be nice to have a script running before npm install that checks these engines versions and if they are available in path.
I created a package that does this.
https://github.com/muuvmuuv/npm-supervisor
It can be run via npm before installation and will check if a version in engines satisfies the global or local installed version.
Related
my company deployed a conan package at their artifactory server. There are several versions of this package available for different configurations. Let's say there are two versions, one for Ubuntu and one for Debian. The urls of these versions are looking like this:
https://artifactory.<my-company>/artifactory/<the-project-depending-on-the-conan-package>/_/<name-of-the-package>/<version-number-of-the-package>/_/0/package/<THE-HASH-FOR-UBUNTU-VERSION>/0/conan_package.tgz
https://artifactory.<my-company>/artifactory/<the-project-depending-on-the-conan-package>/_/<name-of-the-package>/<version-number-of-the-package>/_/0/package/<THE-HASH-FOR-DEBIAN-VERSION>/0/conan_package.tgz
When we build a project, which depends on this package, we need to download the fitting version of it (Ubuntu or Debian). Unfortunately, these downloads need to happen during the build (we use cmake).
Now my question: As you can see, the urls contain the hash of the package versions. But when I build the project, how do I now which hash is for the Ubuntu or the Debian version? Obviously I need to distinguish between the two hashes to download the fitting package-version.
Note: Please assume that my conan-cache is empty.
I hope you guys can help my and please correct my if I there are any missunderstandings (I am new to cmake, conan and artifactory).
I have a Gatsby starter (taylorbryant/gatsby-starter-tailwind) that uses gatsby-plugin-postcss which is not compatible with the version of gatsby installed in my machine like a few other plugins used in the starter. You can see the warning I get when trying to build for production.
warn Plugin gatsby-plugin-postcss is not compatible with your gatsby version 3.14.2 - It requires gatsby#^2.0.0
How can I downgrade Gatsby to a specific version, maybe just locally?
This isn't too difficult.
Open your package.json file and change the actual version you want to use.
Then run npm update to make sure you update all the packages to the right version.
Please correct me if I'm wrong but I believe that is the way to change the Gatsby version.
Please do keep in mind that this is most probably cause a bunch of other discrepancies with other packages that actually require a higher version in order to work.
You can find more information about how different versions work here: https://www.gatsbyjs.com/docs/reference/release-notes/migrating-from-v2-to-v3/
Best of luck!
I've recently installed some npm package (recommended Kubernetes client) for my react app.
After writing code that uses the package and deploying the code for testing I got some weird errors about missing functions or packages. Then I've read the documentation and realized that the package was Node-only.
Is there any way to check that the npm package works in browser before writing code that uses the package?
Python packages specify compatible python versions. Do npm packages have something like this whether they indicate support for particular Node versions and the browsers?
Some packages/libraries contain .browserlistrc file which I've found to be a starting point to find out the browsers and platforms the devs intend to support or have their code compile for. While it may not always be true and the package might just be able to support a browser that isn't mentioned, it's a good starting point. It surely helps to find out if IE (the bane of front-end dev) is supported or not.
Then again many packages don't necessarily include a .browserlistrc. You can then check the package.json for a "browserslist" field.
If neither are found, you can always clone the repo and add your own .browserlistrc in the root with queries that will let you know if the package supports your intended browser or platform - little more work but yeah it can help. Not full proof but a decent enough way to find out.
Though the best answer is really to just ask the maintainers.
We're using NodeJS for some projects and are faced with an issue that must have a simple solution (seeing as nobody else seems to have the problem).
In the packages.json there are a bunch of dependencies mentioned with a minimum version, each of which may have overlapping dependencies of their own. The default way a dependency is added is using the ^ operator which seems to mean 'compatible with' or 'same major version, but minor versions may differ'.
The way I understand npm to work is on npm install to take the highest minor version available that matches. Unfortunately 'compatible with' is not quite as enforced as you'd hope.
The situation this puts us in is that for instance on a developer machine version 1.1.0 is installed, but between development and publishing a new version 1.2.0, that has a bug, is introduced. On our build machine a fresh build is made which ends up using 1.2.0 and we've introduced a bug that wasn't there in development.
We tried changing the ^ operator to = for instance, but this gives us trouble when dependencies have subdependencies that aren't compatible with the requested version.
All in all I'm a bit confused, but this thing keeps biting us anytime something changes since the development machines don't do anything on npm install if the package is already there, but the build machine always gets fresh copies.
I know from NuGet that it always takes the lowest version that matches all combined requirements. Since this is always the same for a given set of dependencies, I much prefer this approach. Is there a way to make npm work like this too?
To answer my own question:
npm has introduced a new command npm ci which does something similar to npm install but enforces that the specific versions are used that were also used when a package was initially added by using the package-lock file.
See https://docs.npmjs.com/cli/ci for more information
I recently got confused and almost installed a tool via brew install when in fact it was an npm package and all I needed to do was npm install -g.
So these tools are strangely similar yet obviously different.
What's the difference in crystal clarity?
NPM exists to resolve dependencies for application code, on a per app basis, allowing an app to be self-contained and portable. This means that (in its default mode of operation) it will install the same stuff many times, uniquely, repeatedly, and separately, for every app on your system that needs the same package, inside of that apps own directory and isolated from everything else.
Homebrew is not like this. The reason is it serves the system itself, not individual apps, so is more comparable to just the npm -g part of npm.
There is one extra bit to understand about homebrew, though - some system packages have specific dependencies and could even have conflicts. This means that for the global installs that homebrew provides, it also has to solve some nesting and conflict issues. It's a kind of magic?