Our app depends on this npm package, all of a sudden it stopped working, and not able to install it again through npm i. How can I fix this?
Error while installing it: mat stepper bar is not in the npm registry
Below is the message from their official webpage
Mat-stepper-bar is a JavaScript package in the npm registry that has been compromised. Our team is working on it :(
If you have any questions, please email us at ngmicroapp#gmail.com
Package status: deleted?
It looks like the package was deleted from NPM recently, since it is still in Google's cache.
Recourse
Unfortunately, there is not much you can do. There is no repository listed in the README or in the published package details - if you knew that the source code lived on a repo in GitHub, you could install the package from there, instead.
Public Mirror?
Your best bet is to try to find a public NPM mirror that still has the package. Aliyun seems to have one, although I am not very familiar with that site and do not know if that is a reliable source.
To prevent this in the future
Use a local NPM mirror
Going forward, you should keep a local NPM mirror if you use volatile packages.
Vet your packages
A better rule of thumb, however, is to avoid relying on relatively unused and undeveloped packages.
Before using a package, ensure that it:
meets basic package cleanliness requirements, such as listing a repository
is well-documented
is well-tested
has a consistent development history, which makes it less likely to be abandoned
has a minimum number stars on GitHub OR forks OR npm downloads
Using a package that fails to meet these requirements adds technical debt to your product, as you are more likely to encounter bugs, take longer to understand undocumented functions, or may discover that the package is renamed or deleted.
Related
Regarding Zero Installs, the Yarn 2 documentation says:
While not a feature in itself, the term "Zero Install" encompasses a lot of Yarn features tailored around one specific goal - to make your projects as stable and fast as possible by removing the main source of entropy from the equation: Yarn itself. [...]
I read the whole story, but didn't really understand that fully.
What is the difference between Yarn 2 Zero Installs and Yarn 2 normal install?
The difference is that using Yarn normal install, you won't need to commit the node_modules (all your deps), whereas, using Zero-Install you will have to take care of all your dependencies.
This certainly makes your dependency on remote repositories less, however, it requires more responsibility, as said in the docs:
Note that, by design, this setup requires that you trust people
modifying your repository. In particular, projects accepting PRs from
external users will have to be careful that the PRs affecting the
package archives are legit (since it would otherwise be possible to a
malicious user to send a PR for a new dependency after having altered
its archive content).
After all, zero-install is a great feature. It solves the "I cloned/switched branch and now a dependency is missing" problem, it speeds up CI significantly and it lowers our dependence on our on-prem npm registry.
I'm a relative newcomer to the node community. I recently got on board so that I could put together a build for a complex web application that's been under development for several years. The two key tools in my build are Grunt and Browserify, but the application uses jQuery, Backbone, d3 and a smattering of other libraries and plugins as well.
A problem that I've been running into is this: by default, when I install and save a package with npm, it sets up the package with a semver expression that captures all future releases of the package whenever you run npm update. Like this article explains well, that may seem like a good thing at first ("give me this package and all future upgrades"), but it exposes your own application to any non-backwards compatible updates the package maintainer makes... The article also provides some recommended best practices, but it was written almost 4 years ago to the day; I'm hoping there are other, newer ideas.
What sort of solutions do you use to resolve this issue? I can't keep wasting time updating my software every time a breaking change is made in a library I rely on. I want to update when I am good and ready, not whenever I run npm update.
Use npm shrinkwrap to save the tree of dependencies containing the exact versions, so when you npm install it'll use those exact versions.
The npm outdated command will tell you what packages are outdated.
Instead of npm update which updates all your packages, update specific packages with npm install <pkg>#<version> --save
For whatever reason this question was flagged as an off-topic on programmers.stackexchange.com.
I still believe it's a legitimate question, so even risking to be kicked again I'm still gonna try to ask it here.
Anyone ever tried gathering any stats on npm packages?
Is it possible for example to read npm low level api (if it even exists) and say get the information about how many packages have underscore.js as their dependency, or how many packages compiled from closurescript, typescript or coffeescript.
I can't believe nobody ever tried to gather and analyze information about all existing npm packages or build dependency graphs and whatnots.
Upd: So most of the packages are hosted on github, and github contains information of the most prolific language in the given git repo. So I guess it is possible to query npm and retrieve detailed information about every single package. And maybe someone already tried doing that?
FWIW, I also don't know of any ready analysis, but,
npm uses couchdb, which is open for replication. See this blog post for a lot of info.
The couchdb contains tar balls that you can further process.
Using Maven, you get Maven repositories. Tools like Nexus ou Artifactory have the ability to mirror (or proxy) remote repositories and self-hosted ones to expose an aggregated view of all downloadable artifacts (or dependencies in the Bower jargon). You get the same mechanism for other dependency managers like Ivy oy Gradle (Maven, Ivy/Ant & Gradle are more than just dependency managers, but it's not the point here).
With Bower, you can set up remote registries from which dependencies will be downloaded. But a great thing in a corporate environment would be to have a self hosted repository working like those describe above.
I have search the Web but did not find any convincing solution. Did you know any of them?
From what I understand Bower uses npm and as such you can use Nodejitsu.
Support for npm repositories is also a requested feature for Nexus. If you are interested in that, vote on the issue and you might see it implemented in the not too distant future ;-)
In the meantime you can potentially use webjars
Update 2015-03-13: NPM support has been available in Nexus OSS and Pro for a while now. Read more about setting it all up in the documentation. However to clarify the Bower repository format is different from the npm format. The Bower team is hoping to move everything to NPM and stop development and hosting, but that is an ongoing effort.
Update 2016-04-11: The new release of Nexus Repository Manager OSS 3.0 has full support for npm and bower.
private-bower provide private bower registry hosting and public registry caching.
Artifactory Pro can do this now. Although the reason I stumbled into this question on StackOverflow is that I'm trying to figure out how precisely to do it. I don't yet follow what if anything I'm supposed to do to support the Repository Layout.
Sonatype Nexus will have support for Bower in Nexus 3. Once this is released, this will probably be the easiest solution, particularly for anyone doing Java development. So make sure you check if this solution is available before just picking the "checked" solution.
Here's the ticket:
https://issues.sonatype.org/browse/NEXUS-6884
Until that happens, go with private-bower:
https://github.com/Hacklone/private-bower
I already installed Express for a hello world app, and worked nice.Now I want create a new app, How can I use the already installed Express for that new app instead reinstalling it for that new app with : npm install express
Or do I have to re-install it frome internet everytime I create a new app?
npm install express
...will install Express only into the current folder path that you have in your terminal. If you want to install the package for all Node.js instances, you'll need to run:
npm -g install express
or, depending on your server's security model,
sudo npm -g install express
Sometimes you'll need to link the package if the linking failed (you'll get a "Cannot find module X" error), via:
sudo npm link express
If you want to read more about it, this blog post is a good read.
Use npm install -g express
But it worths adding express to your package.json with the rest of (future) dependencies you will need, so you can type npm install in your project's root and it will automatically install all the dependecies with the specified version and so on.
Don't install Express globally
Locally installing any package that you're going to depend on is generally considered a best practice in the Nodejs community. It comes down to managing dependencies.
See: Nodejs Blog - NPM 1.0: Global vs Local Installation
Consider the following scenario:
Lets say you do a global install of Express for your first project. You're start off using the latest version of the library and everything goes well. Then over time you write 10 more applications that depend on that install. Eventually Express hits the next main version and adds some killer features but they've also introduced a few backwards-incompatible API changes. You'll want to use the latest version for a new project but a global update will probably break all of the previous applications you've created.
In a best case scenario, you'll have 100% test coverage on all your old projects and through hard work and determination you will eventually manage to update/fix everything that broke with the update.
Realistically, nobody has 100% test coverage on everything and it's likely that something the update broke will be missed and accidentally pushed into production. ::cringe::
The scenario I just outlined is what lots of people refer to as dependency hell. It's a common reason why some organizations get locked into a specific version of a framework/application/dll.
With nodejs, it's cheap and easy to handle dependencies individually for each project. Modules generally aren't as monolithic (read huge) like the frameworks you'd expect in other languages.
To install Express locally with dependencies just use:
npm install express --save
Note: The --save flag will automatically add Express and the version number to your package.json file. If you want the module marked under the devDependencies listing instead, use the --save-dev flag.
The exception to the rule:
The exception to the don't install locally rule is CLI applications. It's rare that someone will write code that depends on a CLI application and -- even if they do -- CLI apps only superficially expose the highest-order functions. Unless the CLI has a development API that you're project depends on, it's probably safe and more convenient to install the package globally.
Aside: A library developer's perspective
As libraries are updated and improved it's not uncommon for library devs to change the API between major versions (ex 1.0, 2.0, 3.0) as they get a better feel for how the everything should be structured. When backwards-incompatible changes are introduced it's not uncommon for people to get all finger-pointy and start bickering about 'poor design'. Most of those issues have little to do with the design of the libraries being used. Rather, they're a cause of poor design and version management from the devs that implement them.
The truth of the matter is, it's impossible foresee a best possible design for a library until most of the code has already been implemented and put to use by a larger community. The best projects are those that grow organically, have a large userbase providing lots of valuable feedback, and adapt over time to their user's needs.
Major versions are usually the most exciting time for library devs because that's where we actually get to release ground-breaking changes. All the versions in between only serve to exist for boring maintenance and bugfixes.
One of the greatest benefits of Nodejs is it's small core. The Javascript language itself is well defined so there's little/no chance that updates to the core will break any code. The second greatest benefit of Nodejs is that the package manager along with the common package.json project file format make managing dependency versions as easy and straightforward as possible.
Source: I develop libraries and spend an obscene amount of time thinking about good API design.