I am getting this error from npm:
Browserify Failed!: Path must be a string. Received undefined while parsing file:
Because browserify works fine on other dev environments around the office I pretty sure it is a npm version issue. Most likely related to an older babel-core. (ref https://github.com/babel/grunt-babel/issues/56)
The fix is to update babel-core to at least 6.10. Here is the list for babel-core.
├─┬ babelify#7.3.0
│ └─┬ babel-core#6.24.1
│ └─┬ babel-register#6.24.1
│ └── babel-core#6.24.1
├─┬ laravel-elixir#5.0.0
│ ├─┬ babelify#7.2.0
│ │ └── babel-core#6.7.2
│ └─┬ gulp-babel#6.1.2
│ └── babel-core#6.7.2
└─┬ laravel-elixir-vueify#1.0.6
└── babel-core#6.7.6
I need to update the copies of babel-core under laravel-elixir only. So how do I do that?
npm -v = 3.10.10
node -v = v6.10.2
Related
I run npm install on a project and get a deprecation error for an underlying dependency.
It is not a direct dependency, it's in node_modules. How can I easily figure out which of my dependencies eventually depends on the problematic library?
A first-pass solution is to use grep, but 2 issues:
This will help me locate the package.json containing the problematic dependency, but there could be 2, 3, 4...n packages between that and my own project's package.json
grep is a bit slow
What's wrong with using npm ls? Here's sample output for a module:
➜ node-address-rfc2821 git:(master) npm ls
address-rfc2821#2.0.0 /Users/matt/git/node-address-rfc2821
├─┬ nearley#2.20.1
│ ├── commander#2.20.3
│ ├── moo#0.5.1
│ ├── railroad-diagrams#1.0.0
│ └─┬ randexp#0.4.6
│ ├── discontinuous-range#1.0.0
│ └── ret#0.1.15
└── punycode#2.1.1
The command npm ls has been around since at least 2011
I have a packages.json file and I'm installing the needed node modules with npm install from the same directory where the file is located.
The problem is that I'm doing this on different machines and some of them might already have some dependencies installed globally.
This normally shouldn't represent a problem but in my case it is.
For example I need to install grunt-contrib-uglify and since some machine might already have some dependencies installed they won't try to fetch and get them. This lead to two slightly different versions of the dependencies tree.
Example:
npm list (truncated) produces:
# Machine 1
├─┬ grunt-contrib-uglify#0.2.7
│ ├─┬ grunt-lib-contrib#0.6.1
│ │ └── zlib-browserify#0.0.1
│ └─┬ uglify-js#2.4.21
│ ├── async#0.2.10
│ ├─┬ source-map#0.1.34
│ │ └── amdefine#0.1.0
│ ├── uglify-to-browserify#1.0.2
│ └─┬ yargs#3.5.4
│ ├── camelcase#1.0.2
│ ├── decamelize#1.0.0
│ ├── window-size#0.1.0
│ └── wordwrap#0.0.2
# Machine2
├─┬ grunt-contrib-uglify#0.2.7
│ ├─┬ grunt-lib-contrib#0.6.1
│ │ └── zlib-browserify#0.0.1
│ └─┬ uglify-js#2.4.23
│ ├── async#0.2.10
│ ├─┬ source-map#0.1.34
│ │ └── amdefine#0.1.0
│ ├── uglify-to-browserify#1.0.2
│ └─┬ yargs#3.5.4
│ ├── camelcase#1.1.0
│ ├── decamelize#1.0.0
│ ├── window-size#0.1.0
│ └── wordwrap#0.0.2
In this case camelcase and uglify-js are not exactly the same version.
When I use this in conjunction with grunt to minify the production js files I get minor differences between the compiled files. Of course the two files acts exactly the same but for git they are different (and I would like to avoid this)
Question: how can I tell npm that I want exactly the same modules but also exactly the same dependencies?
There is a file named package-lock.json. It contains the exact dependency tree of all installed packages including the registry where they were downloaded from. Whenever you add a new dependency using npm install <package-name> this file is updated automatically. It should be checked in into your version control.
To make sure that the same package versions listed in the file are installed in your node_modules folder you have to execute the command npm ci (ci = clean install). This is going to delete your node_modules folder and download the exact packages listed int the package-lock.json. This command should be used instead of npm install in any build script.
I've found the solution: npm-shrinkwrap
So, first I should install and test the modules as normally I would with npm install then run npm shrinkwrap to lock down all the installed modules and their deps into a file called npm-shrinkwrap.json. We could use the flag --dev if we want also to save dev deps.
Then we could for example track this file with git and from other machines retrieve the tracked file.
Then normally npm install => If the file npm-shrinkwrap.json is present it will take precedence over packages.json and npm will use it to install exactly all the deps specified in the file.
I had node, npm, and http-server installed and running. However, when I tried to start up the http-server, I got the following error:
error: Cannot find module 'child-process-close
I have tried uninstalling and re-installing node. That seemed to work just fine, and it looked like it installed http-server properly when I installed it globally with the following command:
npm install -g http-server
However, when I tried to run the server on a directory (I even installed http-server locally in that directory), I get the following error:
zsh: command not found: http-server
When I run this command:
npm ls -g
I get:
/Users/amckemie1/.node/lib
├─┬ http-server#0.7.4
│ ├── colors#1.0.3
│ ├─┬ ecstatic#0.5.8
│ │ ├── he#0.5.0
│ │ ├── mime#1.2.11
│ │ └── minimist#1.1.0
│ ├── opener#1.4.0
│ ├─┬ optimist#0.6.1
│ │ ├── minimist#0.0.10
│ │ └── wordwrap#0.0.2
│ ├─┬ portfinder#0.2.1
│ │ └── mkdirp#0.0.7
│ └─┬ union#0.4.4
│ └── qs#2.3.3
└─┬ npm#2.3.0
etc...
I can't figure out why it can't find the http-server module. I'm guessing it has something to do with my PATH or where the module was installed, but I don't know enough about these factors yet to be able to do much more. Any ideas?
I found the answer to this question here: Global Node modules not installing correctly. Command not found
Brad Parks answer regarding resetting my node install prefix fixed it!
After installing Express with Node.js using this command:
npm install -g express
I am not able to use the express command, I get thrown the error in windows that express is not an internal or external command.
I've checked to make sure Express was installed by using the command npm -g ls and express shows up in there like this:
C:\wamp\www\blackbook>npm -g ls
C:\Users\Chris\AppData\Roaming\npm
└─┬ express#4.0.0
├─┬ accepts#1.0.0
│ ├── mime#1.2.11
│ └── negotiator#0.3.0
├── buffer-crc32#0.2.1
├── cookie#0.1.0
├── cookie-signature#1.0.3
├── debug#0.8.0
├── escape-html#1.0.1
├── fresh#0.2.2
├── merge-descriptors#0.0.2
├── methods#0.1.0
├── parseurl#1.0.1
├── path-to-regexp#0.1.2
├── qs#0.6.6
├── range-parser#1.0.0
├─┬ send#0.2.0
│ └── mime#1.2.11
├─┬ serve-static#1.0.1
│ └─┬ send#0.1.4
│ ├── fresh#0.2.0
│ ├── mime#1.2.11
│ └── range-parser#0.0.4
├─┬ type-is#1.0.0
│ └── mime#1.2.11
└── utils-merge#1.0.0
Any ideas as to what I'm doing wrong or what I can do to fix it so I can use express?
I see you installed the latest Express.js version 4.0.0. In this version they removed the application generation from express itself. This is now a separated module called express-generator.
To install it, use the following command
$ npm install -g express-generator
To read more, check out the Express.js docs #executable
I installed express, mongodb, and mongoose.
This is the result of my npm ls:
/home/merc/Bookings
├─┬ connect-mongo#0.1.9
│ └─┬ mongodb#0.9.9-8
│ └── bson#0.0.4
├─┬ express#3.0.0rc2
│ ├── commander#0.6.1
│ ├─┬ connect#2.4.2
│ │ ├── bytes#0.1.0
│ │ ├── formidable#1.0.11
│ │ ├── pause#0.0.1
│ │ └── qs#0.4.2
│ ├── cookie#0.0.4
│ ├── crc#0.2.0
│ ├── debug#0.7.0
│ ├── fresh#0.1.0
│ ├── methods#0.0.1
│ ├── mkdirp#0.3.3
│ ├── range-parser#0.0.4
│ └─┬ send#0.0.3
│ └── mime#1.2.6
├─┬ jade#0.27.2
│ ├── commander#0.6.1
│ └── mkdirp#0.3.0
├─┬ mongodb#1.1.2
│ └── bson#0.1.1
└─┬ mongoose#3.0.0
├── hooks#0.2.1
├─┬ mongodb#1.1.2
│ └── bson#0.1.1
└── ms#0.1.0
You can clearly see that for some reason Jade is on the root directory (I assume this happened when I run "express". But then again, "mongodb" is available in different versions (0.9.9 and 1.1.2) and so is bson (0.1.1 and a worrying 0.0.4).
Hence my questions: how are dependencies managed with npm? Does every package simple install whatever they like, whichever version they pick?
I guess the question is: is this kind of duplication "normal", and "by design" so to speak?
Merc.
The short answer is, yes, this is by design. When you require a module from the node_modules directory, it uses the top-level directory--e.g., whichever one you specify in your package.json.
Other packages have their own package.json files, and are free to use whatever versions they want, and when they require them down in their own code, they will use their own node_modules folder.
Ideally, the modules you use have tests, etc. that ensure that versions (or even specify a range of versions, such as 0.9.x) of dependencies they specify work well, and seeing older versions of sub-dependencies in there doesn't necessarily mean danger, although new versions of these modules could of course potentially fix bugs and so forth. It may be worth finding a module you're concerned about on GitHub, downloading the repository, updating the package.json and dependencies yourself and running the tests to see if a new version works. If so, perhaps the author would be willing to accept a pull request with your update.