I'm trying to get npm to install node-gitteh as a dependency via npm install which reads from package.json. Unfortunately this npm package is broken in node 0.6.x, but no problem as there's a forked repo that fixes the issues (https://github.com/hughsk/node-gitteh.git).
Now the issue is that this forked repo has a submodule, so if I try to download the tar from github in the package.json:
, "dependencies" : {
"gitteh" : "https://github.com/hughsk/node-gitteh/tarball/master"
}
I get an error that equates to "submodule folder not found". If I clone the same repo manually and do a recursive submodule update and an npm install from the node-gitteh folder, it works fine, but I can't figure out how to get npm to do this.
I've had the same problem and so far have just relied on cloning my module into node_modules and doing a submodule update manually. It would be nice to have npm handle this automatically.
In package.json there's a scripts field (see npm docs)
So could do
"scripts":{"preinstall": "git submodule update -i -r"}
See https://github.com/isaacs/octave-test for an example of this.
According to the docs, you need to supply the git url in a special format.
Also, it needs to point to git repo (same address you would use for git clone), not the tarball provided by github.
In your case (git over https), it would be:
, "dependencies" : {
"gitteh" : "git+https://github.com/hughsk/node-gitteh"
}
Using this, npm will default to the master branch.
Related
Bower install fails with 502 - Bad Gateway when downloading bower packages.
For example bower install for ember library gives following response in command line.
EINVRES Request to https://bower.herokuapp.com/packages/ember failed
with 502
When http://bower.herokuapp.com/ is accessed directly from URL it gives the following message.
This Bower version is deprecated. Please update it: npm install -g
bower. The new registry address is https://registry.bower.io
Bower is deprecating their registry hosted with Heroku. http://bower.herokuapp.com/ Will not be accessible anymore or it might be down intermittently, therefore, forcing users to a new registry.
Users working on old bower versions can update the .bowerrc file with the following data.
{
"registry": "https://registry.bower.io"
}
.bowerrc file can be located at the same folder where bower.json and bower_components folder is located. If it is not present already, you can make one.
For references check the below links
https://twitter.com/bower/status/918073147789889536
https://gist.github.com/sheerun/c04d856a7a368bad2896ff0c4958cb00
Simplest solution is to just upgrade bower to latest version
If installed via NPM:
npm i -g bower
When using asp.net core then should change something like this. bowerrc.json you can find inside project folder.
{
"registry": "https://registry.bower.io",
"directory": "wwwroot/lib"
}
If you use windows to install npm, You must run "Node.js command prompt" with administrator and run this command: npm i -g bower.
I tried and worked :)
echo '{"registry": "https://components.bower.io","directory": "wwwroot/lib"}' > .bowerrc
Ecosystem
using npm#6.1.0
using node#v8.11.1
Context
I have a JS project that includes a local dependencie :
package.json :
"dependencies": {
"my_local_module": "file:my_local_module"
},
Then, I published the project as npm private package : so far everything is OK.
Issue
When I try to install my private package, I have this issue :
33 error code ENOLOCAL
34 error Could not install from "node_modules\#my_scope\my_project\my_local_module" as it does not contain a package.json file.
Of course, the package.json file exists. When I try to copy manually the project from gitHub instead of installing it with npm, it works perfectly fine but I really would like to make it works with :
npm install #my_scope\my_project
Is there a specific way to publish packages when they include local dependencies or anything like that ? Thank you for your help.
You can try to delete your package-lock.json file
I had the same problem and error. The package-lock.json was still doing a reference to "file:my_local_module".
I deleted it and re npm installed the module to make it work
I found a report of a similar issue within the npm cli github
https://github.com/npm/cli/issues/1756
It appears this may be an issue with npm v6 (I was using version 6.14.12). Updating npm to v7 seems to have solved this issue for me.
I am using working from this github issue and it says to use a temporary github fork until a pull request is merged in another repo....cool.
I try to add the github fork to my project dependencies by doing this...
"reactstrap": "git+https://github.com/jameswomack/reactstrap.git",
in the package.json file and when I do a npm install everything goes according to plan, but then I get failures with my project not being able to find reactstrap...
When I go to inspect my node_modules I can see that the reactrap directory is pretty empty with only the LICENSE, README and package.json files...
What am I missing here?
The package.json file of the repository contains these lines:
"files": [
"LICENSE",
"README.md",
"CHANGELOG.md",
"lib",
"dist"
]
This is the list of files and directories to include in the npm package. As you can see, the actual JavaScript files will be located in the lib and dist directories.
The problem is that these directories are not checked into the Git repository, but created by a build, when you run npm run build.
A workaround that I would try: run the build, commit and push the generated files to your fork on GitHub. After that, installing the dependency the way you do it should give you the desired result.
However, if your goal is simply to test if your changes on a local fork of reactstrap work by including it as a dependency of a demo project, there is a better way: use npm link.
It works like this:
in the root of your local clone of your reactstrap fork, execute the command npm link
in the root of your demo project that uses reactstrap as dependency, execute the command npm link reactstrap
Any changes you then do to your reactstrap fork will be available in your demo project immediately.
I have a package (package-a) that depends on another package (package-b) which is not published to npm but is on my file system. When I run npm install from package-a, package-b's dependencies are not installed. I have to navigate to package-b's directory and run npm install manually. Is there a way to install both packages' dependencies with a single npm command?
Here's my directory structure:
/
...
shared/
...
javascript/
...
package-b/
package.json
package-a/
package.json
Per the docs, I placed the following in package-a/package.json. (I'm using npm 5+)
dependencies: {
package-b: "file:../shared/javascript/package-b",
}
When I navigate to /package-a and run npm install, it installs all of package-a's dependencies like normal and also copies the package-b directory to package-a/node_modules. This is presumably what lets me type require('package-b') instead of require('../shared/javascript/package-b') .
However, as I stated before, package-bs dependencies are not installed, so if I try to use package-a, I get an error when package-b is required because it is trying to use dependencies that do not exist locally.
Once again, to solve this, I can navigate to package-b and run npm-install, but I'm hoping there's a better solution as I may have many such sub packages and I'd like to avoid having to write a shell script to go install all my dependencies if I can do this with an npm command. (perhaps I just did something wrong and npm install should be working?)
Follow up question: when I run npm install from package-b's directory, the packages are installed there, but not in the version of package-b that got copied to /package-a/node_modules during the first npm install, yet everything still works. So now it seems like when I require('package-b') it is actually resolving to /shared/javascript/package-b and NOT /package-a/node_modules/package-b. So what's the point of copying the file in the first place?
Update
It turns out this is a bug in npm 5. It only occurrs when installing from a package-lock.json file. (Github Issue)
The files are (probably) not being copied, they're being symbolically linked (symlink). This essentially creates an alias/shortcut that looks like a real directory, but points to another path.
This is how the older npm link feature worked. The reason is the code stays "live"; Changes in the linked module are reflected whenever you run the module that's referencing them, meaning you don't have to npm update all the time.
I love Bundler, it's great at dependency management. I love npm, installing node packages is easy! I have a nodejs app and would love to be able to specify my apps dependencies and easily install / update them wherever I deploy my app. This isn't a library I'm releasing, it's a full fledged web-app.
I'm aware of the npm bundle command, but that just seems to simply override the directory where packages are installed.
I'm used to using bundler in this fashion:
# Gemfile
gem "rails", "3.0.3"
Installs rails v3.0.3 and any other required gems on the host machine only if it doesn't already exist
> bundle install
How can I achieve something similar with npm?
As of npm 1.0 (which is now what you get by default if you follow the steps in the README file), "bundle" is no longer a segregated thing -- it's just "how it works".
So:
Put a package.json file in the root of your project
List your deps in that file
{ "name" : "my-project"
, "version" : "1.0.0"
, "dependencies" : { "express" : "1.0.0" } }
npm install Since you're calling this with no args, and not in global mode, it'll just install all your deps locally.
require("express") and be happy.
Edit: This only applies to npm versions < 1.0
It was quite difficult to figure this out, but NPM makes this possible.
You need three components
A subdirectory in your repository (i.e. deps/)
A package.json file in the above directory that lists dependencies
An index.js file in the above directory that requires your dependencies
Example
Imagine that express is your only dependency
deps/package.json
note: Increment the version # each time you modify the dependencies
{
"name": "myapp_dependencies",
"version": "0.0.1",
"engines": {
"node": "0.4.1"
},
"dependencies":{
"express": "2.0.0beta2"
}
}
deps/index.js
export.modules = {
express: require('express')
//add more
}
Now you should be able to install your dependencies using npm. You could even make this part of your deployment process
cd deps
npm install
Then within your app code you can get access to your specific version of express like this:
var express = require('myapp_dependencies').express;
You should read these two articles from Isaacs(author npm) blog. I think they are really good, and I believe tell you how to achieve your goal:
http://blog.izs.me/post/1675072029/10-cool-things-you-probably-didnt-realize-npm-could-do
http://foohack.com/2010/08/intro-to-npm/
I believe link #1(point #11) explains this:
11: Bundle all your dependencies into the package itself
When you use the
npm bundle command, npm will put all
your dependencies into the
node_modules folder in your package.
But it doesn’t stop there.
If you want to depend on something
that’s not on the registry, you can do
that. Just do this:
npm bundle install
http://github.com/whoever/whatever/tarball/master
This will install the contents of that
tarball into the bundle, and then you
can list it as a dependency, and it
won’t try to install it when your
package gets installed.
This also is handy if you have your
own fork of something, and would
prefer not to change the name.
In fact, you can run almost any npm
command at the bundle. To see what’s
inside, you can do npm bundle ls. To
remove something, do npm bundle rm
thing. And, of course, you can install
multiple versions and activate the one
you want.
As of Npm version 1.1.2 , there's a new command npm shrinkwrap which creates an npm-shrinkwrapped.json file, analogous to Gemfile.lock. It's important to make one, to prevent software rot (see Bundler's rationale). Particularly as Nodejs has such a fast moving community.
While bundle install creates a Gemfile.lock automatically, npm install won't create npm-shrinkwrapped.json (but will use it when it exists). Hence you need to remember to use npm shrinkwrap.
Read a full guide at http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shrinkwrap/
It seems to me that the simplest solution is to use a package.json file with the private flag (added to npm just last month) set to true. That way, you can run npm install or npm bundle to grab your project's dependencies, but you prevent anyone from accidentally publishing your non-public project.
Here's an example package.json:
{
"name": "yourProject"
,"version": "1.0.0"
,"dependencies": { "express" : ">=2.1.0" }
,"private": true
}
Running npm install will install express on the local system if it doesn't already exist; running npm publish gives an error because of the "private": true.
You and your team can use the version tag internally to track dependency changes over time—each time you change a dependency, bump the version. To see which version you've installed, use npm ls installed.
Publish your app with npm as well, and list its dependencies in your package.json file.
When someone uses npm to install your package, npm will take care of resolving its dependencies.
Packages spec: http://wiki.commonjs.org/wiki/Packages/1.0