It's laughable, but actually I've been in the exact situation to prevent a published app from running on Windows, because the app makes specific assumptions wrt shared read/write file access and locking semantics, composing file names, and spawning shell scripts as child processes. So I guess widepread use of is-windows comes from wanting a commonly understood pattern to block running on Windows, not having tested your app on Windows, etc. What's best practice to follow here?
The best practice is (or should be) to develop separate, optimized apps for each system you want to target, and to not build or offer a Windows version if you don't want to support Windows.
OR, since this is just an expression in a single line function, just write it yourself and don't include it as a dependency.
Yes but how to tell npm your app doesn't run on Windows? Checking for win32 or other well-known Win-specific "process" property in your "build" npm script, and make it fail if it hasn't any of the expected valued? I'm guessing is-windows is idiomatically used for this exact purpose, and people not wanting to hard-code a heuristic for detecting Windows in their app. But then, I'm not sure third-party packages are available during execution of "build". The last time I had to deal with this, it didn't work out as I intended, and I ran out of time to find a robust, generally used idiom for this.
