I'm a real noob at this. I've just began scratching the surface on node.js/socket.io/html5 and stuff. I finally figured out how to use my command prompt (using windows) to launch a "hello world" application with the command "node example.js." But what does npm mean? When I'm looking at socket.io it says to install, npm install socket.io Does that mean I need to extract all the files into my nodejs folder?
I'm confused.
npm is a generally awesome program for managing packages and dependencies (especially while you have a network connection). It does lots of fancy things and is most commonly used with node.js projects. That said, it's an unfortunately common misconception that the acronym stands for "node package manager".
In reality, npm doesn't actually stand for anything as it's not an acronym. With taglines like "no problem, meatbag" the npm organization playfully resists the trend of acronymization. It should always be referenced in lowercase to avoid confusion with the National Association of Pastoral Musicians.
npm is a command line interface program to manage node.js libraries (it stands for node package manager - at least it did initially, they since turned this into a bit of a running gag - thanks to #spex in the comments for that link). Check out the docs, it is awesome and amazing. As you mentioned, just type npm install in a command prompt, and voilà, you have the library in your local node modules.
npm is stands for Non-Parametric Mapping utility written by Chris Rorden...
But we can keep it as Node Package Manager and it is very helpful for Module Loader which uses CommmonJS module pattern, and I am not sure will Node will support the ES2015 Module Loading Syntax (Built in module Loading Syntax)?
for those who are wondering the same thing, you just type npm install socket.io in the command prompt where nodejs file is.
C:/Program Files/nodejs
That should be what your command prompt should say and then just type that in.
Related
So I have have been using NPM as a simple build tool for a few years where I can assume that every CLI tool installed through package.json is available in the PATH, as NPM adds the ./node_modules/.bin path to it.
But as I was about to write a small Node script to do some house cleanup chores I got a bit wary if NPM actually has the node executable in the PATH it gives to users. This might seems stupid, as all the scripts in ./node_modules/.bin rely on node being there for the wrapper scripts on Unix to be able to find it, but I thought there might be some magic going on in Windows. Perhaps they use some other magic of their own. Or something. Does not matter, really, I just want to be able to assert:
Is the node executable always on the PATH given to npm scripts by NPM? On all platforms? And is it always the same Node as NPM runs on?
This might seem too basic to almost be asked, but better safe than sorry.
Note: not a definitive answer, but too lengthy for a comment
If you look at the documentation on default values that are set up for scripts:
npm will default some script values based on package contents.
"start": "node server.js":
If there is a server.js file in the root of your package, then npm
will default the start command to node server.js.
Although this isn't a definitive answer to your question, npm uses node as a default in case there's no npm start defined. This is a clear indicator npm relies on node to be present under all circumstances.
On Windows, you can safely make the assumption that npm requires node to be in the PATH, or in the same folder as npm. This is from npm.cmd (the script that is called when you type npm):
SET "NODE_EXE=%~dp0\node.exe"
IF NOT EXIST "%NODE_EXE%" (
SET "NODE_EXE=node"
)
I have written a Electron application using Node, Electron Boilerplate, and phantom. It works perfectly fine for me on my linux machine, I copied the source over to Windows 10, and ran with npm start, and all goes smoothly.
However, when I try to build the application with the boilerplate module using npm run release, things go a little less smoothly. I can install and open the application just fine, but when I click the button that activates the phantom module, the windows goes all white and nothing happens. I was able to logs some errors with the dev tools.
First, I have:
C:\...\dist\win-unpacked\resources\app.asar\node_modules\phantom\lib\phantom.js:361
Uncaught (in promise) Error: Error reading from stdin: Error: write EPIPE(…)
I did some research into similar issues, namely here, and it seems to me the issue is starting the child process, PhantomJS, with the npm module phantom. Originally, I was using a WPF application I wrote in C# to start the process, and that worked just fine. This leads me to believe that the phantom module is the culprit.
So I tried swapping out the npm phantom module for horseman, but got similar results:
Unhandled rejection HeadlessError: Phantom immediately exited with: 4294967295
at ChildProcess.immediateExit (C:\...\dist\win-unpacked\resources\app.asar\node_modules\node-horseman\node_modules\node-phantom-simple\node-phantom-simple.js:153:23)
at ChildProcess.g (events.js:286:16)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at Process.ChildProcess._handle.onexit (internal/child_process.js:204:12)
Here is a shot in the dark. I am not positive this will solve your issue but here it goes:
GYP and miss-matched binaries
Phantom and many other node modules use binaries built for the specific OS that it will be running on. Sometimes in your npm log files you will see references to node-gyp. Node-gyp simply helps to build native add-on's in node modules. When the binaries are built they are usually built against, among others, three main parameters, the operating system, cpu architecture and version of node that is doing the installation.
I think you need to rebuild phantomjs to the version of node Electron is using. Most of the time the node version you have installed on your machine and the node version running in Electron are not the same. Electron does its best to keep up, but there is always a little lag because of the amount of work and testing required to keep up-to-date.
When you install phantom by running npm install phantom it will assume it needs to install or build the binaries for the node version your machine is using. Then when your Electron app tries to run phantom it tries to call the binary of the Electron's node version. When it isn't there the child process immediately exits with an error.
How to fix
Luckily, there are other people out there that have figured out how to fix this issue and have created a great tool to help generate the correct binaries.
Enter electron-rebuild:
https://github.com/electron/electron-rebuild
Electron-rebuild can be run in the command line, and it will rebuild all of your native modules to the version of Electron your project is using.
To install:
npm install electron-prebuilt
To use (in Windows):
.\node_modules\.bin\electron-rebuild.cmd
This should be enough to put the correct binaries in the right place.
Other thoughts
Sometimes you can use a package that uses a dependency called node-pre-gyp. E.g. sqlite3. There is a known issue I ended up running into when trying to rebuild my packages for Electron. Basically, in order to avoid this issue (if you run into it) just append --pre-gyp-fix to the above command.
Tangent for those who run into the pre-gyp-fix issue
One more thing on the pre-gyp-fix: If one or more of your dependencies depends on one of the modules that need the pre-gyp-fix then they will be looking for the binary in the wrong place even if they are running in Electron. All of the pre-gyp binaries are stored in a folder similar to this:
.\node_modules\sqlite3\lib\binding
In my current project I have three folders here, one for Electron-v1.4, and two for node-v46 and node-v50. (hack alert) In order to have sqlite3 work with my other dependencies I copy the binary found in the Electron-v1.4 folder and put it in both node-v* folders. That way when running in Electron, all dependencies are running the correct binaries even though they are looking for them in the wrong place. (end hack alert)
Conclusion
There is no way I can be sure this has anything to do with the issue you are seeing. But it is worth a shot to see if it fixes your problem. If not then at least I hope I can help someone else experiencing the same issues I ran into.
My current npm version is 3.7.3 . Previously, only the required packages were getting installed in my node modules. But right now they have all flattened and have 100 + folders visible when I look into node modules. I prefer the older way where you could go into individual folders and see their dependencies.
here is a similar thread:
Why does npm install many packages into "/node_modules" instead of only one?
I tried running npm uninstall without much success.
Basically, you are out of luck... NPM does not provide any configuration options regarding this. It will nest dependencies if it must in order to resolve version conflicts, but only in this case. Your only option is to downgrade NPM (not recommended). However, if you just need to see the dependencies nested for informational reasons, you can use npm ls. It will draw you a graph.
See this relevant NPM issue for more discussion: https://github.com/npm/npm/issues/9809
Now that node js' LTS doesn't include an NPMv2 I found myself stuck with this issue again.
For those of you also caught out, the link that #KevinBurdett mentioned, also has some answers.
You can force downgrade npm using npm itself (using sudo or equivalent for this). From https://github.com/npm/npm/issues/9809#issuecomment-179702479:
as root I simply do npm install -g 'npm#<3' on my system every time I
a new version of Node comes out; your mileage might vary, but it's
fairly trivial to "downgrade" :-)
Another alternative is to use the Node Version Manager (NVM): https://github.com/creationix/nvm. Your mileage may vary depending upon personal config/preferences/platform.
That said, npm 3 and the issue of flat dependency trees will be with us from hereafter... It's probably high time to start accepting that change.
My personal grudge with this is that it makes the node_modules folder incredibly difficult to work with in an IDE, especially when you need to look at the implementation of your immediate dependent modules, without first wading through 100's of sub-sub modules that are irrelevant to me. It seems that I'm not alone in this matter when you read the comments in the issue. It only leads me to question the viability of npm itself when such changes are made without a proper migration from old to new systems. For me, npm2 will always be king.
I'm new to Electron, and I really love it so far, but I'm unable to package any of mine apps, at first I thought that it's maybe something related to my code, then I download "https://github.com/atom/electron-quick-start" run npm install and then I run "electron-packager . FooBar --platform=darwin --arch=x64 --version=0.28.2" it build the app but when I try to open it I get
so I didn't touch any code from the example, just wanted to build it and I got an error, what am I doing wrong? Thanks!
The versions of electron are moving very very fast.
And some times, they don't respect the "old" ways to do things (for example, declaring the app).
I advise you to not use the 0.28.2 version of electron but the most recent one.
It is very likely that the version of electron-prebuilt you are using to develop is much much much more recent than the 0.28.2 version. So, you are developing with something much newer, and then you are building with 0.28.2. This would cause the exact error that you are seeing, as older versions may not have had the electron module, which your code explicitly is importing. So... that is my suggestion. Change the version in your electron-packager command from 0.28.2 to something like 0.36.0. See if that works. Or better yet, use the same version as electron-prebuilt in your package.json.
This could be a combination of factors.
First, as others stated, the version of electron that you have might be newer than the one referenced in your build command. Locate the 'electron_prebuilt' folder inside your 'node_modules' folder, and examine the package.json file and make sure the version # is the same as what you are declaring in your build command.
If they are the same, then the issue might be that you have another version of electron on your computer that node is trying to use. If you installed electron via the -g option (global), check your home folder to see if there is another different version of electron. If you find one, either delete it or rename the 'electron_prebuilt' folder you find to something else. Try your build command again, and it should work now that you've eliminated the other versions of electron_prebuilt on your computer that node was referencing.
What worked for me was to move the "electron" module from "dev-dependencies" to "dependencies" in package.json. Try this and see if it works.
Full error/warning log: http://pastebin.com/xNjC4FDr
I had problem as well when I tried to install MongoDB, I have made SO question of it but, that was only warnings, so I could ignore it. But this time it's not only warnings, but also red error.
What do I have to do? Is my Nodejs messed up because I've installed Visual Studio Tools for NodeJS in the past? Or is this normal behavior? What can I do about this, I prefer not to see errors/warnings when I install something on NPM.
The problem is that hiredis does not support Windows currently. The link to the Windows-compatible fork in the hiredis readme seems to be outdated (last commit in 8/2013 as of this writing), so you may be out of luck.
However hiredis is not required by the redis module, it's an optional dependency that just makes parsing the redis protocol faster than the pure JavaScript parser that is bundled with redis. You may see a similar thing with other modules that have optional dependencies like this. Typically if you see the module tree outline at the end of the console output, that means the module installation was successful.