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!
Related
I have monorepo setup and upgraded from yarn 2 to npm 7.
Was working perfectly fine till I tried to deploy my application to the standard app engine environment.
gcloud app deploy kicks off a build inside Cloud Build, which builds my project via buildpacks (nodejs14 buildpack).
My problem is, that this buildpack includes nodejs14 and npm#6 and without using the flex environment it doesn't seem that there is a way to use npm#7 in this standard app engine cloud build.
What I've tried by now:
Use same OS and install node_modules, tar them, upload them, untar them. (could not really do it)
Link packages locally before uploading (don't know if I did that right. App was not finding local packages afterwards)
Trying to use a cloudbuild.yaml, but it seems that this is not possible with standard environment.
in the custom build step "gcp-build": "npm i -g npm#7" (does not work, permission error, see full build log here)
I would really appreciate every pointer in any direction that could help me out.
This is my project setup:
[project]/
├── packages/
│ ├── app
│ │ ├── node_modules/
│ │ ├── src/
│ │ ├── app.yaml
│ │ ├── ...
│ │ └── package.json
│ ├── shared
│ │ ├── node_modules/
│ │ ├── src/
│ │ ├── ...
│ │ └── package.json
│ ├── shared-admin
│ │ ├── node_modules/
│ │ ├── src/
│ │ ├── ...
│ │ └── package.json
│ ├── base-server
│ │ ├── node_modules/
│ │ ├── src/
│ │ ├── ...
│ │ └── package.json
├── package.json
│
└── node_modules/
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
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.
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.