设置后如何将Express.js用于新的Web应用程序？

Question

我已经为一个hello world应用程序安装了Express，并且运行良好。现在我想创建一个新应用程序，如何使用已安装的Express用于该新应用程序，而不是使用以下方法为该新应用程序重新安装它： npm install express每次创建新应用时都可以从Internet重新安装它？

Answer 1

Use npm install -g express

But it worths adding express to your package.json with the rest of (future) dependencies you will need, so you can type npm install in your project's root and it will automatically install all the dependecies with the specified version and so on.

Answer 2

npm install express

...will install Express only into the current folder path that you have in your terminal. If you want to install the package for all Node.js instances, you'll need to run:

npm -g install express 

or, depending on your server's security model,

sudo npm -g install express

Sometimes you'll need to link the package if the linking failed (you'll get a "Cannot find module X" error), via:

sudo npm link express

If you want to read more about it, this blog post is a good read.

Answer 3

Don't install Express globally

Locally installing any package that you're going to depend on is generally considered a best practice in the Nodejs community. It comes down to managing dependencies.

See: Nodejs Blog - NPM 1.0: Global vs Local Installation

Consider the following scenario:

Lets say you do a global install of Express for your first project. You're start off using the latest version of the library and everything goes well. Then over time you write 10 more applications that depend on that install. Eventually Express hits the next main version and adds some killer features but they've also introduced a few backwards-incompatible API changes. You'll want to use the latest version for a new project but a global update will probably break all of the previous applications you've created.

In a best case scenario, you'll have 100% test coverage on all your old projects and through hard work and determination you will eventually manage to update/fix everything that broke with the update.

Realistically, nobody has 100% test coverage on everything and it's likely that something the update broke will be missed and accidentally pushed into production. ::cringe::

The scenario I just outlined is what lots of people refer to as dependency hell. It's a common reason why some organizations get locked into a specific version of a framework/application/dll.

With nodejs, it's cheap and easy to handle dependencies individually for each project. Modules generally aren't as monolithic (read huge) like the frameworks you'd expect in other languages.

To install Express locally with dependencies just use:

npm install express --save

Note: The --save flag will automatically add Express and the version number to your package.json file. If you want the module marked under the devDependencies listing instead, use the --save-dev flag.

The exception to the rule:

The exception to the don't install locally rule is CLI applications. It's rare that someone will write code that depends on a CLI application and -- even if they do -- CLI apps only superficially expose the highest-order functions. Unless the CLI has a development API that you're project depends on, it's probably safe and more convenient to install the package globally.

Aside: A library developer's perspective

As libraries are updated and improved it's not uncommon for library devs to change the API between major versions (ex 1.0, 2.0, 3.0) as they get a better feel for how the everything should be structured. When backwards-incompatible changes are introduced it's not uncommon for people to get all finger-pointy and start bickering about 'poor design'. Most of those issues have little to do with the design of the libraries being used. Rather, they're a cause of poor design and version management from the devs that implement them.

The truth of the matter is, it's impossible foresee a best possible design for a library until most of the code has already been implemented and put to use by a larger community. The best projects are those that grow organically, have a large userbase providing lots of valuable feedback, and adapt over time to their user's needs.

Major versions are usually the most exciting time for library devs because that's where we actually get to release ground-breaking changes. All the versions in between only serve to exist for boring maintenance and bugfixes.

One of the greatest benefits of Nodejs is it's small core. The Javascript language itself is well defined so there's little/no chance that updates to the core will break any code. The second greatest benefit of Nodejs is that the package manager along with the common package.json project file format make managing dependency versions as easy and straightforward as possible.

Source: I develop libraries and spend an obscene amount of time thinking about good API design.