Enhancement: Use win32 platform specific casing for env.path if present

[mattezell]

There are certain scenarios that may give rise to difficult to diagnose issues stemming from path inconsistency issues introduced further upstream in the npm pipeline before landing in lifecycle.

While it's not lifecycle's responsibility to sanitize env pairs, it would be nice if lifecycle preferred OS specific path casing when it's present, vs iterating through all case insensitive matches before using on the last match.

Consider the following being set upstream from lifecycle:

process.env['Path'] = 'c:\\path\\one';
process.env['PATH'] = 'c:\\path\\two';

When instantiated, lifecycle currently evaluates process.env keys with a case insensitive regex match within a forEach - selecting the last match as the path casing that will be used for the remainder of lifecycle processes (including modifying the path with module specific paths). In this scenario, 'PATH' will be used within lifecycle - though ultimately process.env will be passed containing both 'PATH' and 'Path' - at which time win32 platforms will use 'Path' when instantiating the native a Process() instance. Of course, since lifecycle opted for 'PATH' due to it being the last case insensitive match, path modifications that may be required won't be picked up by Process(), which may lead to failure.

I have personally dealt with such a failure, which ultimately resulted in a difficult to diagnose issue with the increasingly popular opencollective and lightcollective libraries being called in postinstall by 3rd party dependencies. While this issue may be mitigated by authors simply adding "|| exit 0" to their postinstall calls to external libraries, not all authors are easily convinced to make this change. There are many reported issues surrounding opencollective and lightercollective erroring with "is not recognized as an internal or external command", specifically on Windows - I figure that it's likely that this is frequently an underlying cause.

I propose that lifecycle use the OS-specific path casing when present on process.env - only falling back to iterating through the keys in search of an alternate when the OS-specific casing isn't present. Pull request imminent.

[mattezell]

@zkat or @aeschright is this the appropriate place for PRs for npm-lifecycle? After submitting this last week, I notice this repo doesn't appear to get much activity, which led me to question if I'd perhaps submitted this to the wrong place. Thanks!

[mattezell]

@isaacs, do you know these repos are actively monitored/maintained? Is there a more appropriate place to open issues and submit PRs? Thanks!