Feature: Support for OS-specific "scripts" properties in package.json

[clintharris]

It's hard to find a cross-OS way to run commands like install, start, test, etc., without using an intermediary Node script to do conditional platform-checking and spawning, etc. For example, many people have "install" reference a make file; it would be nice to offer a .bat file version for win32 support.

There was a discussion about this in November--not sure if anything happened with it... Isaac suggested the following:

Here's a proposal, just a straw man to get it started. If there's no objection, we can go with this, and see how it works:

{ ...
, "overlay":
 { "win32": { "dependencies": { ... }, "scripts": { ... } }
}

So, it would only be allowed for hash-type fields (not description, name, version, and other "string" things), and would fold in rather than overwrite. Setting something to "null" should delete it from the hash.

So, if you had this:

{ "name": "foo"
, "version": "1.2.3"
, "bin": { "foo": "./bin/foo.js", "foo-bar": "./bin/bar.js" }
, "scripts": { "install": "make install }
, "dependencies": { "baz": "1.2.7", "blerg": "1.5.3" }
, "overlay":
 { "win32":
   { "bin": { "foo-bar": null }
   , "scripts": { "preinstall": "win-configure.bat", "install":
"win-make.bat" }
   , "dependencies": { "blerg": "1.4.7" }
   }
 }
}

this would result on windows as:

{ "name": "foo"
, "version": "1.2.3"
, "bin": { "foo": "./bin/foo.js" }  // foo-bar removed
, "scripts":
 { "preinstall": "win-configure.bat" // added
 , "install": "win-make.bat" // changed
 }
, "dependencies": { "baz": "1.2.7", "blerg": "1.4.7" } // blerg modified
}

[isaacs]

This will never be done in npm.

Use a *.gyp file to compile platform-specific binaries in a portable manner.

There is no other valid use case for install scripts, and eventually non-gyp install scripts will not be supported.

Use prepublish scripts to do anything else you need to do to generate artifacts for your package. prepublish is run on your machine, so it can be platform-specific without any problem.

[dscape]

There is no other valid use case for install scripts, and eventually non-gyp install scripts will not be supported.

Would love to have you talk to our engineering team about this @isaacs — i think we use non-gyp install scripts in production. Sure our engineers wouldn't mind migrating to a "better" way, but I'm trying to make sure the functionality we depend on does not get deprecated here

cc @mmalecki @jhs

[ThomasDeutsch]

I call Windows PowerShell scripts from my package.json file.

{
    "name": "my-silly-app",
    "version": "1.2.3",
    "scripts": {
        "myTestScript": "@powershell -NoProfile -ExecutionPolicy unrestricted -Command ./test.ps1"
    }
}

Why? Because unix-people learn bash, windows-people learn powershell :)

I think that an OS specific package would make sense - or at least a warning message.

[oliverjanik]

This would be great, our team develops on different OSes and even simple things are complicated. There's absolutely need for this.

Take a simple example of export NODE_ENV=production vs set NODE_ENV=production

I find it frustrating how Node community is aggressive towards Windows users. I've seen several issues closed in haste without any consideration at all with bold statements like the one by @isaacs .

Node needs to stop marketing itself as cross-platform if all you support is mac/linux and make everyones else's life a living hell.

Please reopen and let's have a civilized discussion.

[dead-claudia]

@isaacs Please consider opening this again. This is coming from a Linux user, but not everyone uses Linux. Occasionally, I have to support Windows users as well, and native addons complicate this picture tremendously.

[HaykoKoryun]

I concur, we have an issue right now with migrating polymer elements from bower to yarn/npm and I have to write a script that copies over a module in the root of node_modules into a different subdirectory since the include path is incorrect, and it will be a while until the issue is fixed.

The script is very simple: cp -r ./node_modules/web-animations-js ./node_modules/@polymer/web-animations-js however in Windows this will totally not work out of the box. Right now the solution is to create a small js file that handles the logic of running different commands based on the OS when it could be much simpler if this was possible right from package.json.

[perguth]

In context of Docker we would like to differentiate between MacOS and Linux. Inside Docker on MacOS nodemon needs to run with --legacy-watch (polling) to recognize file changes. Would be nice, but Node can't tell the hosts OS anyway.

[simeyla]

@pguth then how does it know it is optional?

I think you know more than I do, but that's a very confusing statement given this message :

SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.1.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})

[dead-claudia]

@simeyla I think the gist of @pguth's problem is that:

1. On non-Linux platforms, Docker runs in a Linux VM.
2. VMs don't expose the host OS for security reasons.
3. In macOS, the VM uses a broken POSIX API instead of the working FSEvents one to shim in the filesystem changes.

Their issues are independent of this bug, and are that of a missing workaround within Docker's VM.

[houd1ni]

@isiahmeadows @oliverjanik
You'll be surprised, but I've come after MacOS and Ubuntu-linux inconsistence.
There's -r flag with xargs util, that crashes on MacOS and absolutely needs to be on linux to be consistent with MacOS.