I do not have Node.js installed on my machine.
I have been given the source code of an application that is coded in Node.js, Express and AngularJS.
To determine the Angular.js version like any other client side javascript library I can just open the filename and get the version.
In the root folder of my application there is a node_modules folder but there is nowhere I can see what version of Node.js it is for. It does have a debug subdirectory that contains Node.js but opening the file doesn't show me the version number.
When I go to the Node.js website it gives me two version options: 4.5 or 6.5. Which one should I use if I don't even know the version the source code is written in?
Since node.js is not bundled with the source code you have to find out yourself. Is there a package.json in the application's root directory? The desired node.js version might be declared at "engines". Beside that the dependencies of your application might have some requirements. So installing node.js 4.5 LTS and running npm install might give some insight.
Are tests present? If there's a reasonable code coverage, running them could give you some safety in guessing if every feature will work with your installed version of node.js.
Usually the dependencies listed in your package.json will dictate the node version you have to use. So if npm install works you're off to a good start. An exception may be if the original author used ES6 features, which means you have to run a quite recent version.
Related
I have a pretty common (i guess) problem. Many of my projects utilize nodejs, some for business logic, others only for some building task.
I need to have different runtimes in different projects, one of my electron apps requires node 7.10.0, a typical build suite requires node 8.x.
Now i know - i can use sudo n 7.10.0 or sudo n latest to switch the runtime globally on my computer (For those, who dont know this - have a look at "n")
Anyway, IMO this is not so convenient (some times, i need to rebuild all the modules after switching versions, often i forget to switch and so on). Is there a way of telling node which interpreter to use? Can i use a .npmrc file in a project directory to force a specific nodejs version within that subdirectory?
I searched exactly for this (npmrc node version) but was not lucky enough to find something.
Okay, i found a similar quesion:
Automatically switch to correct version of Node based on project
it seems you can install "avn" and use a .node-version file to do exactly that.
sudo npm install -g avn avn-n
avn setup
then you can create a .node-version file in your project and enter the desired version
echo 7.10.0 > .node-version
Then avn will detect that and activate the correct version
Unfortunately i get an additional permissions error. So to make this work, you need to install/configure "n" to work without sudo/root.
If you're fine with using another tool you could use nvshim.
pip install nvshim # this is all you need to do
It does not slow your shell startup or switching directories, instead moving the lookup of which node version to when you call node, npm or npx by shimming those binaries. More details in the docs.
Source, I wrote the tool.
NVM (Node Version Manager) allow us to use different versions of node quite easily on a single machine. You can have a look at here how to configure and use it.
Volta can used to manage multiple nodejs, npm or yarn versions on different projects on same machine. It's cross-platform.
For example you can run volta pin node#14 in project directory and this will set node to v14 if it exists otherwise it will download and then set it.
More information here https://docs.volta.sh/guide/
I am trying to figure out an effective way to bundle and distribute various dependencies (node modules and/or "client"-side scripts and framework like Angular) with my Electron App.
Although the basic approach of npm install module-name --save works well for development, it is not so good in the end when it comes to minimizing the size of your app and using minified resources at runtime. For instance, virtually all npm packages (including node modules) come with a lot of "extra baggage" like readmes, various versions of components (minified, not minified, ES2015, no-ES2015, etc). While these are great for development, all these files have absolutely no need to be included in the version you will be distributing.
Currently there seem to be 2 ways to sort of address the problem:
Electron Builder recommends using 2-file package.json system.
Any dependency that is used during development only should be npm-installed using --save-dev and then prunning should be used when building the app for distribution.
In that regard I have several questions:
I am not quite sure why there is a need for 2-file package.json system if one can install dev-only modules/ dependencies with --save-dev and then use pruning during the actual app build/compilation?
Regardless of which method above is used, you still end up with full npm packages in your app, inclduying all the miscellaneous/duplicated files that are not used by your app. So how does one "prune" so to speak the npm packages themselves so that only the actual files that are being used at run-time (like minified scripts) get included?
Will using Bower for "client-side" packages (like AngularJS 2, Bootstrap, jQuery, etc.) and using npm for node modules (like fs-extra) be a better option in as far as separation of concerns and ease of bundling later?
Could WebPack be used to produce only the needed files, at least for the "cient-side", so that only real node modules will be included with the app, while the rest of it will be in the form of web-pack compiled set of files?
Any practical tips on how this bundling of dependencies and distribution should be accredited out in practice? Gulp-scripts? Web-pack scripts? Project structure?
Thank you.
I am still in the learning curve of adopting the best practices in code deployment. But here is my starting list of what is recommended.
Yes, npm install --save-dev is the first easiest thing to isolate dev and build specific packages. This includes gulp/grunt/webpack and its loaders or additional packages. These are used only for building and never in the code that actually is run. All packages used by the app should be installed with npm install --save so that it is project level available. So, in production, you would no npm install --production in machines which will not install dev packages at all. See What's the difference between dependencies, devDependencies and peerDependencies in npm package.json file? for more info.
While the original recommendation was to use bower for client side and npm for server side, both can be installed using npm too. After all, both does the same job of managing the packages and dependencies. However, if web pack is used, it is recommended that npm is used for client side dependencies also.
package.json should be thought of managing the dependent packages only and not for building. For building and picking only the required files, you need task runners like gulp/grunt or bundlers like web pack.
While gulp/grunt is very popular for build automation which includes bundling all dependent javascript in file and minifying them in to one file, webpack/browserify is a better option as it supports module import. Module import is intuitive way of require one module in another in node js type of coding
var util = require('./myapp/lib/utils.js') This is powerful way of mentioning the required dependencies in the code. The web pack builder runs like gulp as build process. But instead of looking through html file for all js files, looks at starting js file and and determines all dependent code mentioned by the require statements recursively and packages accordingly. It also minifies the code. It also loads css and image files in one bundle to reduce server trips. If needed, some modules can be configured to be loaded at runtime dynamically further reducing page load. NPM vs. Bower vs. Browserify vs. Gulp vs. Grunt vs. Webpack discusses this at length.
Webpack can be used to bundle client side app optimally while server side need not be bundled or minified as there is no download.
In web pack, though you can mention dependent modules with lib file path, the recommendation is to npm install all dependencies and mention the module name. For example if you have installed jquery, instead of giving path like /libs/jquery.min.js, you can mention as 'jquery'. Webpack will automatically pull the jquery lib and dependencies and minimise it. If they are common modules, it will be chunked too. So, it is better to npm install dependent packages instead of bower install.
ES2015 provides lot of benefits during coding time including type checking and modules. However all browsers do not yet support the spec natively. So you need to transpile the code to older version that browsers understand. This is done by transpilers like Babel that can be run with gulp. Webpack has in-built babel loader so web pack understands ES2015. It is recommended to use ES2015 module system as it will soon become the defacto way of coding and since there is transpiler, there is no worry of this not being supported in IE8/9.
For project structure you could have
server
client
src containing js files
dist containing html and build files generated
webpack.dev.config.js and webpack.prod.config.js can be at root level.
I have found that this area is an ocean and different schools of best practices.This is probably one set of best practices. Feel free to choose the set that works for your scenario. Look forward for more comments to add to this set.
I started a tutorial on Angular 2.0, the first step in setting up the workspace is installing Node.js and NPM.
Why do we have install Node.js for Angular 2.0?
I don't remember doing this for angular 1.X.
Technically, Node.js and NPM are not needed to do Angular2 work. It does ease things though. Here's the main reasons I speculate are behind this choice:
CLI: Since a while now the de facto way to build and develop new Angular apps is to use the CLI tooling which relies on Node and NPM as well.
TypeScript: Examples are .ts, and you need to run a compiler step to get them into .js, which can be done on-the-fly easily with Node.js and NPM (plus it's a way of easily getting typing files);
Web Server: Serving your Angular SPA from a "real" albeit light web server prevents probably some nasty issues that come with checking your site using file:// links.
The Quickstart guide itself actually continues to mention some more concrete reasons as well:
Here's what these scripts do:
npm start - runs the compiler and a server at the same time, both in "watch mode"
npm run tsc - runs the TypeScript compiler once
npm run tsc:w - runs the TypeScript compiler in watch mode; the process keeps running, awaiting changes to TypeScript files and re-compiling when it sees them
npm run lite - runs the lite-server, a light-weight, static file server with excellent support for Angular apps that use routing
npm run typings - runs the typings tool separately
npm run postinstall - called by npm automatically after it successfully completes package installation. This script installs the TypeScript definition files defined in typings.json
You can also have a look at the Quickstart source and further dive into where NPM is needed.
Footnote: there's a similar question about needing Node.js for AngularJS (1.x).
Because Anglar2 is based on Typescript, Web Components and ES6 which need compilation for performance and broader browser support. Typescript is compiled to ES5 JavaScript and the other features require shims for backwards compatibility.
Since Typescript is a superset of JavaScript, and it's compiled to JavaScript anyway, you can write your code in plain JavaScript but it's not recommended.
For a more detailed explanation check out these videos on YouTube
Why Typescript
Instalation steps
NodeJS gives you the tool npm that allows you to download libraries and packages you would use in Angular 2. From the shell you can go to your folder and type npm install to install dependencies you need to have installed to get your angular project going. It will make it easier for you! If you want a complete starter kit go to https://github.com/buckyroberts, you can fork or download the zip with all the starter files to get you going :)
You do not need to use Node anywhere in production to use any front-end JavaScript framework, whether it is jQuery, AngularJS, ReactJS, Angular2, etc.
Angular2 can be used in isolation but to get and feel better development environment, angular2 should be used with nodejs and npm. Some of the nodejs modules helps you in web development.
Node.js is sometimes confusing when it comes to version management...
I am trying to arrange various projects as i am doing with ruby projects. For example:
With ruby i can create file such as .rvmrc and fill with something like rvm --create use 1.9.3#my-app
This thing creates and uses all gems specifically to configured gemset. Which allows to have various options for any kind of project, and switch easily among them. So ruby does this in one place.
I want to achieve this for node.js projects.
Node works differently. I want to know the details about that, and especially of each node version management tool.
The point is to know which version management tool for which goal...
And why there are so many.
More accurately: i want npm install <package-name> to chosen node version. And after switching to other versions, this installed package to be missing, or have different version installed before (or certain one). Just like gemset is working.
I've been looking for clarification too:
Both allow switching & installing between node versions.
nvm will symlink the different versions to /usr/local/bin/node, and n will move your node installs to the path (/usr/local/bin/node).
n downloads and installs binary files, and nvm downloads, compiles, installs from the source.
I don't fully understand the latter part of your question, but in regards having control with node projects/apps, you can use npm install [package_name] --save-dev to save your npms within your 'project'.
These npm module versions (^semver) get detailed in your package.json file, for example "gulp": "^3.8.5" is different from "gulp": "3.8.5" (the later being specific to v3.8.5, and the ^3.8.5 means allowing any future version of 3, but not 4.0.0)
The differences between npm and gem is that npm installs the specified packages in the local node_modules folder (the current working directory using the --save-dev), so you have less worries with cross project module versions.
Important note: Running --save (instead of --save-dev) installs any missing dependencies.
I hope that helps a little :o)
Just tried to install nvm and it works for switching from one version to another. In header of nave.sh it says "# This program contains parts of narwhal's "sea" program, as well as bits borrowed from Tim Caswell's "nvm"", so you might try both and see the tiniest difference. Also check the "popularity" of each and contributors to get some insight). There is also a nodeenv which uses python, but I don't any reason why use python here. So, my answer would be no big difference.
I've been using Node.js and npm for a few weeks with great success and have started to question the best practice for installing local modules. I understand the Global vs Local argument, however, my question has more to do with where to place a local install. Let's say that I have a project located at ~/ProjectA/ which is version controlled and worked on by multiple developers. When initially playing with Node.js and npm I wasn't aware of the default local installation paths and just simply installed the necessary modules in a default terminal which resulted in a installation path of ~/node_modules. What this ended up doing is requiring all the other developers working on the project to install the modules on their own machines in order to run the application. Having seen where some of the developers ran npm install I'm still really surprised that it worked on their machines at all (I guess it relates to how Node.js and require() looks for modules), but needless to say, it worked.
Now that the project is getting past the "toying around" stage, I would like to setup the project folder correctly. So, my question is, should the modules be installed at ~/ProjectA/node_modules and therefore be part of the version controlled project files, or should it continue to be located at a developer-machine specific location...or does it not really matter at all?
I'm just looking for a little "best-practice" guidance on this one and what others do when setting up your projects.
I think that the "best practice" here is to keep the dependencies within the project folder.
Almostly all Node projects I've seen so far (I'm a Node developer has about 8 months now) do that.
You don't need to version control the dependencies. That's how I manage my Node projects:
Keep the versions locked in the package.json file, so everyone gets the same working version, or use the npm shrinkwrap command in your project root.
Add the node_modules folder to your VCS ignore file (I use git, so mine is .gitignore)
Be happy, you're done!