I don't believe it's necessary. If the user has forked a project and is installing via a raw git repo, they could add a commit to cause preinstall to run the prepublish script if needed, and leave it alone if they don't.

I am with @dfellis after thinking 2 days about this and I am still not sure haha.

My thoughts are:

• if a package is promoted to be installed via git, this would be unnecessary anyway. the developer will make sure it works.
• if a package is actually in the registry but installed via git, the user knows what he is doing and will do as @dfellis mentioned (or any other solution)
• the devDependencies-problem sucks, prepublish is meant to be run on the developer-side

But I think it should be mentioned in the docs maybe?

use case:

• condition: package needs to be compiled before installation, e.g. from coffeescript to javascript
• condition: compiled files are not welcome in the repository
• goal: allow developer to publish package in registry in a compiled state, so common users do not need any pre/postinstall
• goal: allow users to install a different versions or forks of the package from git repos without having to do anything special (e.g. as a project dependencies)

sample current solution by @paulmillr at https://github.com/brunch/brunch:

• on prepublish compile all and manually turn off postinstall in package,json
• on postpublish reenable postinstall
• on postinstall (which runs only when installed via git, as it is disabled in packages in registry): compile all

limitations:

• clearly devDependencies will need to be installed for packages with prepublish installed via git repo ... this is ok as long as users did really need to run preinstall, in this case it is the right thing to do
• complex prepublish scripts may depend on other development tools, that may not be available on user machines

options:

1. don't do anything, let developers solve that like in https://github.com/brunch/brunch ... imho awkward
2. run prepublish on git install ... will fail packages with complex prepublish scripts installed via git repo (but currently they were just installed unbuilt anyway) and force people to simple, or all-js scripts (may be both a good practice, and maybe too restrictive in some cases)
3. add and run gitinstalll on installing via git repo, install gitDependencies in that case ... adds new settings, but breaks no compatibility and solves the issue, my 2c

I agree. npm install with no args already runs the prepublish script for the same reason, so it would make sense to do the same for git urls.

I also agree. Repositories are for the source files, why should we have to add extra bulk (especially for larger packages)?
Since the idea of version control is to control the source, npm should assume that only the source is contained in a git repo and run prepublish when installing a package from git. It is theoretically identical to installing a package in a local directory.

Any updates?

npm has 861 open issues and is a bit behind at handling them. It will take a while to respond.

I personally would appreciate if I didn't get notifications about people inquiring about updates, but, alas.

Yes, between this and #1876 I can't figure out any good way to use a forked module in dependent project, without publishing it to the public repo.

Backstory: I'm trying to get https://github.com/natevw/node-hid/tree/dhleong/Node-0.11.13 building for atom-shell on Windows. Somethings odd, and I'm trying to simplify how the build process works, but between these two issues there's not really a good way depend on git submodules in a non-published node module.

@natevw: try npm shrinkwrap, which is infuriating to use in the longer term, but can help with what you're describing.

@braco Thanks for documenting that, it is similar to what I ended up doing (which was to make a GitHub release tarball and install that instead).

By the time a Git URL's source code makes it to my node_modules, the repo's .npmignore has been applied.

the developer will make sure it works.

I don't get the full source from which to build. So I can't make sure it works. Not within package.json, anyway.