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
Related
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.
Im a java programmer currently working on a java webapp. Managing javascript can be quite painful.
Recently i came across this js dependency manager bower. However it requires both node and npm to be installed.
1) Just wondering if there are side effects to installing node. For example cpu and memory usage. And are there upsides to it other than bower?
2) Is there a way i can turn off the node service when im not using it.
3) In addition, been looking around and cant seem to find a bower like solution that runs natively on windows
Bower is now considered as an obsolete package manager, and the general advice is to use npm package registry (which is by default in npm). I don't even think that there are packages which are bower exclusively. There are different package managers, but they use npm registry too (like yarn, for instance).
Regarding your questions:
1) No, there are no side effects, except your disk space. Node is not a demon, it is just an application to run javascript code – so if you don't start it, it doesn't consume anything (of course, installing some npm dependency uses node under the hood).
2) No need to.
3) Almost all package managers (including bower) work on Windows good. Actually, almost all JS ecosystem now works quite good and stable on Windows.
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
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.
I like the look of meteor, never tried it before, thought it would make a great platform for a web dashboard on my raspberry pi. Tried the recommended installer and got this:
$ curl install.meteor.com | /bin/sh
Unable to install Meteor on unsupported architecture: armv6l
Installation failed.
Well, I'm not gonna take that lying down! Am going to try and manually install it, but has anyone tried/failed/succeeded already? Any tips?
Apparently, there are prebuilt packages for raspi now. Alas, I lost interest long ago - details of prebuilt packages here: http://meteor-universal.tumblr.com/
(Thanks to #Archonic - see the comments below - and if you'd like to make that a real answer, I'd be happy to change the accepted answer for this question.)
I'll keep the text below for reference.
(Updating as I go along...)
Note: i'm doing this on the stock debian image, albeit after having installed ruby, passenger and padrino (and all their dependencies). Archlinux may be easier, I don't know.
Install node.js
Does not work by default, followed instructions here
Checkout meteor
git clone git://github.com/meteor/meteor.git
modify admin/generate-dev-bundle.sh
Essentially, remove all the instructions regarding building node.js, and all references to a tempdir, so you end up just installing node packages. I will post mine as a gist once it's all figured out...
Then, run it in an empty folder
install mongodb. From source.
cd to extracted directory, and install using scons
sudo apt-get install scons libboost-all-dev
scons libboost-dev libpcre++-dev xulrunner-1.9.1-dev
(Note: I will be finishing this soon. I think the trick might be to use meteor's bundle functionality - especially the big red box http://docs.meteor.com/#deploying - but unfortunately my pi has crashed and I'm away from home. Please post if you found that worked, and I'll update this answer accordingly or accept your answer)
You can find a fork of meteor at github called Meteor universal fork. That has a ready to go installer for yet unsupported architectures like ARM and BSD.
For the installation just run:
cd $HOME
git clone --depth 1 https://github.com/4commerce-technologies-AG/meteor.git
and then get the binaries and finish the installation by:
$HOME/meteor/meteor --version
Running the above command for the first time will try to download a compatible pre-built dev_bundle and finish the installation. Depending on your hardware this may take some time.