Skip to content

[RFC] Should there be an npm module for the dotslash executable? #50

Closed

Description

@bolinfest

Should there be an npm module for DotSlash that contains the dotslash executable for multiple platforms (and/or the npm module fetches the platform-specific dotslash in postinstall, though that could fail in the presence of --ignore-scripts?) so that once that one-time cost is paid, it's easier for other modules in the Node.js ecosystem to distribute executables using DotSlash?

For example, suppose you have a DotSlash file for my-example-tool. Then perhaps the package.json for the my-example-tool module looks something like:

{
  "name": "my-example-tool",
  "bin": {
    "my-example-tool": "dotslash ./my-example-tool-dotslash-file"
  },
  "scripts": {
    "postinstall": "dotslash -- fetch ./my-example-tool-dotslash-file"
  },
  "dependencies": {
    "@meta/dotslash": "0.1.0"
  },
}

@zertosh curious to get your thoughts on this one.

Activity

  1. bigfootjon commented on May 6, 2025

    @bigfootjon
    Contributor

    Yeah I think this is a great idea, but I'm not sure anyone at Meta really has the bandwidth to work on this. If you're willing to set up the code to publish the package and do the initial package setup I can wrangle the permission bits to transfer the package over to Meta.

    or the npm module fetches the platform-specific dotslash in postinstall

    I'm -1 on this, I think we should just publish the package with all the binaries needed. This is the norm for npm packaging AFAIK.

  2. bolinfest commented on May 14, 2025

    @bolinfest
    ContributorAuthor

    @bigfootjon I don't know what the norm is, and we do try to keep dotslash pretty small, so perhaps bundling everything is the right thing to do (and works better for folks who vendor their own yarn-offline-modules, for example), but https://www.npmjs.com/package/@vscode/ripgrep is one module that I know fetches the arch-specific rg binary in postinstall.

    I'll look into getting the right bits in place.

    That said, it would be nice to cut a new release now that #48 is in so we can get the arch-specific Mac binaries out there. Generating the Node.js module should probably piggyback off of GitHub releases like @vscode/ripgrep does.

  3. zertosh commented on May 15, 2025

    @zertosh
    Contributor

    Should there be an npm module for DotSlash that contains the dotslash executable for multiple platforms

    I'm really in favor of this! There are quite a few tools doing this. Meta even does this for flow-bin.

  4. bolinfest commented on May 15, 2025

    @bolinfest
    ContributorAuthor

    https://github.com/flow/flow-bin/blob/main/index.js last touched 4 years ago to add support for arm64 linux, though no separate binary for arm64 macOS :P @mroch you gotta get with the times!

  5. bigfootjon commented on May 19, 2025

    @bigfootjon
    Contributor

    That said, it would be nice to cut a new release now that #48 is in so we can get the arch-specific Mac binaries out there.

    Sorry for the delay, I'm cutting a new release now

  6. added a commit that references this issue on May 19, 2025
  7. motiz88 commented on Jun 30, 2025

    @motiz88
    Contributor

    Hey @bigfootjon, I'm happy to take you up on this:

    If you're willing to set up the code to publish the package and do the initial package setup I can wrangle the permission bits to transfer the package over to Meta.

    (My team has a use case for this as part of a future iteration of React Native DevTools.)

    See #74. I'm not super well-versed in GitHub Actions so haven't worked on that part yet, but with the current state of the PR, publishing is as simple as

    cd node
    npm ci
    npm run lint
    npm run build -- --version $RELEASED_DOTSLASH_VERSION # add --prerelease for testing
    npm publish
    
  8. added a commit that references this issue on Aug 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions