Support npm 5 prepare script for installing non-published references

[intellix]

npm 5 added the ability to specify a prepare script inside package.json. It's basically how to prepare a package before you want to publish it (build it).

When a package has a prepare script and you depend on a git source, npm will:

1. Install it's devDependencies
2. Run the prepare script

With it, you can depend directly on git sources without the need to publish them to npm first, which means you can depend on commits, branches or tags from a repository. For example:

"graphql": "github:graphql/graphql-js#some-new-branch"

Whenever I do a PR, it's because I need that code now and want to reference it straight away to start using it, so I typically reference my fork like: github:intellix/graphql-js#some-fix

Quote about prepare from npm docs:

prepare: Run both BEFORE the package is packed and published, and on local npm install without any arguments (See below). This is run AFTER prepublish, but BEFORE prepublishOnly.

It can essentially be a copy of the build command:

"prepare": "npm run build"

Spoke a little about this in: #1340

[IvanGoncharov]

Whenever I do a PR, it's because I need that code now and want to reference it straight away to start using it, so I typically reference my fork like: github:intellix/graphql-js#some-fix

I have the exact same use case, I maintain my own fork of graphql-js to be used in my projects, e.g.:
https://github.com/APIs-guru/graphql-faker/blob/0c1dd3814c8bb5ad1582d3ad736b6f91696de0ab/package.json#L48

Main problem with this feature is that prepare script should work on ALL suported node versions and across ALL enviroments.
In reality it mean prepare should work on Windows and we can't use shell scripts anymore.

I'm personally was surprised on how easy it's to break build on Windows, e.g. you can't defined env variable using VAR=VALUE command and instead you need to use cross-env.

That's why we will definetly need CI test that ensure prepare on Windows.

So even though I personaly would love to use such feature I think it requires too much maintaince.

[mjmahone]

Is this significantly different from relying on the npm branch? That branch is automatically updated after any pull request is merged and all tests pass.

[intellix]

The difference is that the npm branch is only master, and since npm5 you can point to any branch or commit from any fork, so once you submit a pull-request, it's instantly dependable without any hack

[jaydenseric]

@intellix wow how did I not realise this before, about using prepare to enable Git dependencies, thanks! There have been times I tried installing a fork/PR as a Git dependency and gave up, most recently with a graphql-relay PR.

I've begun rolling it out for all my packages, starting with graphql-api-koa.

Off topic, but that package is probably also a good reference for using Babel v7 with --keep-file-extension to distribute .mjs files, avoiding the nasty renaming and moving shell script. It's a good thing to have the source files use the right .js or .mjs extensions. Something that doesn't seem to be talked about much is using ESLint overrides config to make sure .mjs and .js files are parsed with the right sourceType and to ensure require and import syntax is only used in the correct environments. The more aligned source code is with dist output the better.