A clean way to install a top-level app via npm

[gh-andre]

npm is great for maintaining package dependencies, but there's no clean way to install a top-level app - it is assumed that it is installed in some unspecified way before npm install runs. It would be nice if it was possible to install top-level apps the same way one would do with other package managers, like dnf, apt, etc, which distinguish standalone apps and dependencies and work equally well for both.

In other words, I would typically run something like this when building a package:

git clone --branch=2.0.0 repo://.../myapp
npm install
npm run build
npm run start

The first step can be anything - clone, deploy a source archive, run a separate installer or use a different package manager. Problem is, such steps are outside of the npm realm and may be error-prone to whether the right tag is used when cloning, whether the person running it forgets one of the steps, and so on. If I could publish the app package built with the first three steps and users could install it as a top-level app (i.e. no package.json in the target directory when installing it), that would keep the entire process within npm.

Effectively, it is as if I ran these steps - no need for the build step because the package would already contain all artifacts in bin, doc, etc.

npm pack [email protected]
tar xvzf myapp-1.2.3.tgz --strip-components=1
npm install
npm run start

Having an app-level package would make DevOps simpler by just being able to manage builds as packages in an Artifactory- or Azure DevOps-like virtual package repositories and have QA simply point their environments to those virtual repositories to install the app being tested without having to deal with source repositories and build steps.

[ljharb]

The app could expose a binary through the "bin" field, and then instead of npm run start, you'd run npx app-start (or whatever you named the bin), and npm wouldn't need to add any features to support that.

[gh-andre]

In order to run anything from the bin folder, one needs to install the app first, which is what this post really is about - how to install a Node app as an app and not a dependency.

[ljharb]

npm install -g $app?

[gh-andre]

Not the same. In my original post in npm/rfc I actually mentioned that, but decided to remove it in this post, but can see how it would be useful.

This is not about global installation, but rather a top-level app installation. Think how you install apps via dnf - you just install them and they pull dependencies as needed and figures out whether it's a local app or not. Same thing here and people do this now all the time, just manually by doing all sorts of things - clones, zip packages, other package formats that expand into Node apps, etc. It would be very straightforward if one could just install a top level app via the standard package manager.

[MylesBorins]

Hey @gh-andre I've read your original post as well as the thread and I don't think I'm entirely understanding what is not accommodated by npm install -g $DEP

You can run npm install -g on any package published to the npm registry as well as any git host or tarball as documented here

A package is able to define what binaries it exports in the bin field in the package.json, and is able to define everything needed to build prior to publish using things such as the pre-publish script and can define anything needed to be automated after the install using the postinstall script.

prepublish and prepare are often used when doing system agnostic transformations such as transpilation (babel / TS / rollup / webpack) where the postinstall scripts tend to be used for system specific stuff such as install / compiling platform specific binaries.

With all of this put together you can npm isntall -g or npx and have a system wide executable available in the path. You can modify where this is installed by default for both node + npm by utilizing prefix so you can decide if you want something to be system wide or scoped per user.

If for example you are using a tool like nvm to manage your Node.js installation your "global" install will scope not only to a specific user but to a specific installation of node.js.

With all of these things together it seems like we already do everything you are asking for. Please let me know if I missed something.

[gh-andre]

@MylesBorins

There's a logical difference between an app package and a package providing dependencies, which translates into how each is used. This difference has nothing to do with whether the application is installed locally or globally. Yes, one can hack what I'm describing as a global app, but that will not address this difference.

Say, I want to install and run two instances of the same application with different configurations - all I need for this is two different installation directories and the rest just works. You would need to jump through the hoops to do it with a global app.

A local app is a local app and I am doing this today by manually handling artifacts/packages that I know to be applications, while there is the perfect delivery system for this - npm, which already has absolutely everything one needs for this, except a switch somewhere to indicate whether it's an app or a dependency.

It would make life easier for many end users and DevOps users consuming non-utility type of applications applications, which are not well-suited to be installed globally. All they need to do is to point to their registry and rely on versions and scripts to install applications reliably, as opposed to pulling custom-packaged artifacts with their own versioning schemes.

[MylesBorins]

Any package that you install in an application creates an entry in /node_modules/.bin for the exported bin that is scoped to the application that it is been installed in. I actually include an entry for this in my bash profile

I'll be honest that I'm still not clearly understanding how the solutions we have are not sufficient for the problem you are outlining. To the best of my understanding package managers like apt install a single instance of a package at a global level and make an executable available at a known location you can add to your path. It isn't clear to me how npm does not offer the same thing

[gh-andre]

To the best of my understanding package managers like apt install a single instance

Package managers like apt, dnf, etc, are designed to work system-wide and even though some may provide non-mainstream options to relocate packages, people who want to install packages locally on Linux just follow the well-established path of installing into /usr/local from source distributions, which is completely outside of apt's realm.

npm, on the other hand, puts --global apps into /usr/local and runs non-global apps from the app's folder, so, unlike apt, it is perfectly aware of local installations. In other words, npm fully supports running apps locally, but does not support installing apps locally, except from proprietary source packages, which takes us back to the original point of such packages not having standard properties and behaviors, even though they all do exactly what npm would do if apps were allowed to be installed locally.