deno install changes for Deno 2

[bartlomieju]

We'd like to change deno install subcommand in Deno 2 to align it better with user expectations.

EDIT (28.05.2024):
Some of the changes have already landed, further TODOs:

• deno.json workspace support for Deno 2 #22942
• workspace: specifier not supported for package.json dependency #18192
• perf(cli): Optimize setting up node_modules on macOS #23980
• Benchmark deno i, bun i, pnpm i, yarn i #23375
• feat: Handle package.json lifecycle scripts #23558
• perf: Optimize installing npm deps on mac [WIP] #23573

Currently deno install is used to install script as globally available executables:

$ deno install https://deno.land/[email protected]/http/file_server.ts
file_server
Listening on ...

While this is super useful and convenient there's a mismatch in expectations to what this command does, especially for users coming from npm/yarn/pnpm background.

Proposed changes to deno install include:

• Keep the current behavior when -g or --global flag is provided - this mimics how package managers from Node ecosystem work. This will require minimal changes on the user side and is implemented in feat(install): require -g / --global flag #23060. We need to ensure that it works correctly for jsr: specifiers too.
• • The same
• If deno install is run without -g flag then it will behave like current deno add subcommand - it will create an entry in deno.json(c) file's import section. We will need to add support for http:https:// and https:// specifiers. This makes it an almost drop-in replacement for npm/yarn/pnpm install <package> (minus that we default to jsr: specifiers and npm packages require npm: prefix).
• The --root and --force flags would only be available if -g/`--global flag is provided, as they make no sense in non-global context.
• The same changes should be applied to deno uninstall - without -g/--global flag this subcommand would operate on local deno.json(c) file, otherwise it would act for "globally available" executables.
• We should add support for package.json as well - if jsr: specifier is used, we should set up proper .npmrc file

We want to enable (some of) these changes in Deno v1.42 and v1.43 with DENO_FUTURE=1 env variable, so users can try it out as soon as possible.

[Leokuma]

I would prefer to keep deno install and deno add as they are. Usage can be confusing when there are 2 commands to do the exact same thing. And now deno install is left with arguments that make no sense if you don't use -g.

In npm it kind of makes sense to use npm install and npm install -g because it's all about downloading node_modules. But in Deno we didn't want to have to worry about node_modules, so using deno install instead of deno add doesn't make as much sense.

[NfNitLoop]

I'd like to give a strong second to @Leokuma's feedback.

there's a mismatch in expectations to what this command does, especially for users coming from npm/yarn/pnpm background

I'd argue that the only mismatch in expectations is for those coming from the Node ecosystem. Coming from Rust/Cargo, "install" and "add" make perfect sense.

Making deno install have two entirely different behaviors and arguments just to mimic the bad behavior from the node ecosystem feels like a regression in Deno. Deno's a chance to do this better!

Plus, --global feels like the wrong flag. Whether you've added a dependency to your local deno.json (with the current deno add behavior) or you've installed it as an executable (current deno install behavior), both are downloaded and cached into the same global cache.

I'd love to keep the existing deno install behavior so that we don't have to update docs everywhere when Deno 2 rolls out. But if you want to make deno install more approachable, I think a better path would be to make two explicit separate commands, instead of hiding two commands in one with a -g flag. (Look at git for the usability nightmare that results from making a command with the same name do drastically different things depending on arguments/context.)

• Remove deno install. Calling it should output instructions that you want to use one of the other commands:
• deno install-script is the old deno install behavior. But it's explicitly only for installing an executable script.
• deno add is what folks from npm are looking for to add a dependency to the current project.

No flags needed!

[Leokuma]

Also, if people are not willing to learn even Deno CLI commands - which should be the very first thing to be done, and it takes 1min -, what are they willing to learn about Deno at all? They will also complain that $ deno main.js doesn't run the script, and then we'll change it so it does and aligns with Node users' expectations.

We should make it easy for Node people to migrate to Deno rather than turn Deno into Node.

[cknight]

If I understand this change correctly, it will result in the following:

• deno install -g jsr:@someScope/somePkg will "install" an executable deno script in the users bin directory (current behaviour)
• deno install jsr:@someScope/somePkg will add the dependency to the deno.json

The differences of behaviour here are very unintuitive. Even the '-g' flag doesn't make a lot of sense to me. Why is 'global' associated with an executable script and lack of 'global' associated with adding a dependency? This flag makes more sense in the node ecosystem where the global flag denotes 'package downloaded for use by all node projects' vs 'package downloaded for only this project'.

Overall, it feels as if this change introduces more confusion than it will solve and I'm not a big fan of the two different use cases for the same command.