Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Support non-JavaScript executables in "bin" #6422

Open
1 of 2 tasks
nex3 opened this issue Jul 30, 2024 · 0 comments
Open
1 of 2 tasks

[Feature] Support non-JavaScript executables in "bin" #6422

nex3 opened this issue Jul 30, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@nex3
Copy link

nex3 commented Jul 30, 2024

  • I'd be willing to implement this feature (contributing guide)
  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant