You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This feature is important to have in this repository; a contrib plugin wouldn't do
Describe the user story
It's useful to be able to use npm to distribute executables that are not strictly written in JavaScript. My specific case is the sass-embedded package, which wraps a native sass executable in a JavaScript API. Providing direct, efficient access to that executable is valuable, but if I need to wrap it in a JavaScript library that produces substantial overhead both in terms of efficiency (I measure about 450ms of pure overhead on my laptop) and in terms of accuracy (Node.js is not very graceful about wrapping executables, so edge cases like signal handling often end up working weirdly).
Describe the solution you'd like
npm already supports this by allowing any executable file in the "bin" section of a package.json file. Yarn currently breaks compatibility by always attempting to run these files as Node.js source. Matching npm's behavior is the minimal solution I'd like to see.
However, npm doesn't gracefully support cross-platform packages in this way (npm/cmd-shim#152). Having additional support for distinguishing between bin/executable and bin/executable.cmd, or explicitly specifying per-platform executables, would be a substantial value-add.
Describe the drawbacks of your solution
This does likely involve maintaining some amount of shim code for Windows, which is always a pain in the ass because of how weird cmd.exe is.
Describe alternatives you've considered
This can't be a plugin because it's intrinsic to the way Yarn installs and exposes executables in a variety of contexts. The current workaround is to write a custom JavaScript shim, but this poses the efficiency and correctness issues I outlined above. Another option could be to add a post-install script to manually set up executables in the user's directories, but this is likely to substantially step on the package manager's toes.
The text was updated successfully, but these errors were encountered:
Describe the user story
It's useful to be able to use npm to distribute executables that are not strictly written in JavaScript. My specific case is the
sass-embedded
package, which wraps a nativesass
executable in a JavaScript API. Providing direct, efficient access to that executable is valuable, but if I need to wrap it in a JavaScript library that produces substantial overhead both in terms of efficiency (I measure about 450ms of pure overhead on my laptop) and in terms of accuracy (Node.js is not very graceful about wrapping executables, so edge cases like signal handling often end up working weirdly).Describe the solution you'd like
npm already supports this by allowing any executable file in the
"bin"
section of a package.json file. Yarn currently breaks compatibility by always attempting to run these files as Node.js source. Matching npm's behavior is the minimal solution I'd like to see.However, npm doesn't gracefully support cross-platform packages in this way (npm/cmd-shim#152). Having additional support for distinguishing between
bin/executable
andbin/executable.cmd
, or explicitly specifying per-platform executables, would be a substantial value-add.Describe the drawbacks of your solution
This does likely involve maintaining some amount of shim code for Windows, which is always a pain in the ass because of how weird cmd.exe is.
Describe alternatives you've considered
This can't be a plugin because it's intrinsic to the way Yarn installs and exposes executables in a variety of contexts. The current workaround is to write a custom JavaScript shim, but this poses the efficiency and correctness issues I outlined above. Another option could be to add a post-install script to manually set up executables in the user's directories, but this is likely to substantially step on the package manager's toes.
The text was updated successfully, but these errors were encountered: