Document `sv` command name collision with runit

[craumix]

The sv command is the same as the one used by runit and therefore running npx sv will not actually run the Svelte CLI and you will get a very confusing error message instead:

❯ npx sv create my-app
fail: my-app: unable to change to service directory: file does not exist

Running the CLI requires running it as, for example, npx sv@latest, this is not a huge problem but might be worth mentioning in the docs, for example in the "Creating a project" section, to avoid problems and unnecessary support requests.

[dominikg]

a little more information about runit would have been nice.

It looks like it is a mostly non-standard init for unix/linux https://smarden.org/runit/ , as such very few users are using it.

The larger issue here seems to be that npx favors a local binary over a registry package when no version specifier is given.
Are other pms eg pnpm dlx sv also sharing this behavior?

[Conduitry]

I can't reproduce the behavior where npx tries running a binary in my PATH rather than using a package from the registry.

edit: Ah. I can if the binary is in the same directory as npx is, and not just somewhere in my PATH. npm exec sv doesn't help either, and seems to prefer binaries in the same directory as npm.

edit again: pnpm dlx sv and pnpx sv seem to prefer the sv package over a local sv binary, even if it's in the same directory as pnpm/pnpx.

[AdrianGonz97]

Had a run-in with this while authoring: antfu-collective/package-manager-detector#15 for sv's check and migrate commands.

bunx and npx are the only ones that (annoyingly) use the same command to execute local and remote binaries. They both prioritize locally installed binaries over fetching the remote package if a version specifier is omitted. Meanwhile, yarn and pnpm fetches the package every time with yarn dlx and pnpm dlx (pnpx being the alias for this).

To execute local binaries only with pnpm and yarn, you would run pnpm exec sv and yarn exec sv (or as a shorthand, pnpm sv and yarn sv).

Not sure if this is something that needs to be explicitly called out in the docs though. This issue could serve as an easily searchable solution. If we had an FAQ section in the docs, I guess it can go there too.

[manuel3108]

Not sure if this is something that needs to be explicitly called out in the docs though. This issue could serve as an easily searchable solution. If we had an FAQ section in the docs, I guess it can go there too.

I think this could be enough of an edge case to just ignore it. But it could fit in an FAQ section

[catielanier]

Quite frankly, I don't see too much of an issue just to say to write the documentation as npx sv@latest create my-app just to:

• Make sure user is running most recent version instead of stale versions, which will run into less issues while troubleshooting/reporting stale issues
• Preventing namespace issues such as the runit based one, thus saving a nonzero size chunk of people time googling the issue (Googling did not net me my answer until I created a redundant issue here)

A very small amount of work for less headaches all around down the line.

[notramo]

Worth noting that Void Linux uses runit as init system, so all Void Linux users are affected.

I wonder, why this tool was named sv instead of svelte?

[Conduitry]

It was called sv rather than svelte so that the main svelte package on npm doesn't need to have all the dependencies necessary to run the CLI, which are only needed for people scaffolding and migrating Svelte apps, and not by those running them.

[benmccann]

bunx and npx are the only ones that (annoyingly) use the same command to execute local and remote binaries. They both prioritize locally installed binaries over fetching the remote package if a version specifier is omitted. Meanwhile, yarn and pnpm fetches the package every time with yarn dlx and pnpm dlx (pnpx being the alias for this).

I found npx -c, which appears only executes the local package. We should probably update package-manager-detector to use that for local execution. But I guess what we want in this issue is the reverse where we do only remote execution. Can anyone check if npx -p sv helps in this case?

I filed oven-sh/bun#15427 as a request for bun

[catielanier]

Are there any checks within npx/bunx for system packages of the same name? If not, I think the better solution would either be to incorporate that or always expect to run remotely downloaded binaries within them, which would require pull requests on those packages. I’m not sure if there’s really any benefit to just calling local packages at all when you call npx/bunx since both attempt to refresh the remote package when called, so it feels like assuming whatever is pulled remotely is the only binary an sh session will find is a major oversight, and probably doesn’t just affect Void/runit users.

…

On Tue, Nov 26, 2024 at 14:02 Ben McCann ***@***.***> wrote: bunx and npx are the only ones that (annoyingly) use the same command to execute local and remote binaries. They both prioritize locally installed binaries over fetching the remote package if a version specifier is omitted. Meanwhile, yarn and pnpm fetches the package every time with yarn dlx and pnpm dlx (pnpx being the alias for this). I found npx -c, which appears only executes the local package. We should probably update package-manager-detector to use that for local execution. But I guess what we want in this issue is the reverse where we do only remote execution. Can anyone check if npx -p sv helps in this case? I filed oven-sh/bun#15427 <oven-sh/bun#15427> as a request for bun — Reply to this email directly, view it on GitHub <#259 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIH4NJSDOZ3EZ42QORLLXID2CTAUJAVCNFSM6AAAAABQ6GPSOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBRG4YTEMJUGI> . You are receiving this because you commented.Message ID: ***@***.***>