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/std@0.22.0/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:// 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.

[jeff-hykin]

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?

Surprisingly yes it does make a difference, humans are weird like that. I wouldnt think so either but I have cognitive science background, I can confirm every bit of friction makes an exponential difference in adoption. Its like having someone randomly change one of the keyboard shortcuts you use on the daily. It creates an annoyance and that annoyance gets associated with deno.

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

This I agree with 100%. Theres ways to lower friction without turning deno into node

[jeff-hykin]

I think a deno npm subcommand would be useful for helping people switch. deno npm install --global, deno npm init, deno npm run. It could print out the deno equivalent command, the caveats, while also doing the close-enough equivalent. It would avoid documentation updates, annoying all of us existing deno guys, and avoid muddying the pure deno API.

If that solution is ignored, then I'm in favor of @NfNitLoop 's solution. Rename install to something else.

In particular, if theres ever going to be local scripts (think npx) then install [script] --local is going to be hella confusing. And on the flip side, if theres ever going to be a global import map, like deno add npm:lodash --global then the install --global is going to conflict.

And if that solution is ignored, then I'd even be in favor of deprecating deno add instead of having two ways of doing the same thing. Deno 2.0 is the time to break things, two ways of doing the same thing is instant legacy code

[Seally]

Surprisingly yes it does make a difference, humans are weird like that. I wouldnt think so either but I have cognitive science background, I can confirm every bit of friction makes an exponential difference in adoption.

I agree and don't need a cognitive science background to confirm this. However, changes like this can be seen as a choice regarding which groups you want to cater to and which groups you're willing to annoy.

Any changes to command names will annoy existing Deno users and users who are more familiar with the existing command names. Even when catering to Node users, npm is not the only Node package manager. Two other commonly used ones include Yarn (Classic and Berry) and pnpm. Both of them use add <pkg> for adding dependencies and install for the initial project setup. For global packages, Yarn Classic uses yarn global add (Yarn Berry removed this outright in favour of yarn dlx) while pnpm uses pnpm add -g.

I will also note that, at least to me, if a command "installs" foo I will assume that it also fetches foo and places it somewhere I can use. Notably, I'd expect that after running the command I'd be able to turn off my internet and use foo (to an extent). If a command "adds" foo, I'd have fewer preconceptions regarding what it does besides adding foo somewhere, so it's more suitable if the command simply adds a line to a file and leaves the download for later.

Personally, I'm currently in favour of @NfNitLoop's proposal the most, especially deno install-script. deno install confused me the first time I saw the command. It wasn't clear to me what it did from the name alone. deno install-script is slightly more verbose, but much clearer regarding its purpose. It's not a commonly used command for me, so I'm fine with the increased verbosity, and an alias could be defined if length becomes an issue.

[bartlomieju]

All of the changes described in this issue were implemented and shipped in the past few releases. You can try them out in earnest upgrading to Deno 2.0.0-rc.0:

deno upgrade --canary
deno upgrade 2.0.0-rc.0

[jeff-hykin]

Yarn (Classic and Berry) and pnpm. Both of them use add

Solid point

deno install confused me the first time I saw the command

Same.

I also really struggled when googling how to global install something for deno. "How to Install deno" results kept flooding out how to install a script. deno install-script won't necessarily make it more google-able but it certainly wont hurt.

[bartlomieju]

Closing this one as all the changes from this issue are already implemented.

[martin-braun]

I support this change, it was very confusing learning about deno install.

Now I wish a simple deno install would run deno run install, so I can specify a proper task to install all local deps, such as:

    "install": "deno cache --reload --config=deno.json --lock=lock.json deps.ts",

@bartlomieju I know this is not NPM, but I kinda want to improve the onboarding experience of my project for people who know and love NPM.

Can I somehow alias deno install (and only deno install) to run deno run install?

[bartlomieju]

You'd need to provide a shell alias to do that.