Install via npm

[MarkTiedemann]

I guess npm would be the most familiar way for Node developers to install Deno.

So how about a simple postinstall script in the package.json so you can run npm install deno to install Deno into $HOME/.deno/bin?

npmjs.com/deno is already taken by a "Bridge to deno" package that only has a README so far, but we could ask the author of that package to transfer ownership.

The TypeScript declaration files could be published in the package, too.

If we did that, editors that don't know about Deno, but that do understand TypeScript and auto-download declaration files for code-completion from npm (for example, VS Code), would make it very convenient to get started: You would just have to create a my-script.ts file, open it in your editor, type import * as deno from 'deno', and the editor would give you auto-complete, so you could type deno.en, hit tab, deno.env() would be auto-completed, and you could hover over deno.env() with your mouse to read the docs ... That would be very convenient. :)

[Nima-Ra]

I think one of the main reasons for using Deno is npm.
With Deno we don't want any NPM and node_modules :)
So I don't think that it is a very clever idea for us!
P.S: README.MD file says:

• No package.json. No npm. Not explicitly compatible with Node.

[qti3e]

@Nima-Ra Hi Nima, glad to see you here :)

Even though Deno is not going to support npm internally as a JS package manager, here we are more likely talking about npm as just a package manager.
A lot of JS devs already have npm on their systems, just like bower or apt so those who want to move from the Node land to the Deno land, can easily install deno binary on their computer using a single command line command.

So I'm +1 on this.

[styfle]

It looks like @YounGoat already published to npm

https://www.npmjs.com/package/deno

[justjavac]

I created dvm to manage and install multiple versions of deno, inspired by nvm

[vladimyr]

A lot of JS devs already have npm on their systems, just like bower or apt so those who want to move from the Node land to the Deno land, can easily install deno binary on their computer using a single command line command.

Those who have npm likely have npx too. I thought it would be nice if people could just execute:

$ npx get-deno [version]

to install specified (or latest) version. It didn't exist so I decided to accept the challenge: get-deno.
It is really a toy grade script compared to @justjavac's dvm but it should be sufficient for initial migration step.

[sholladay]

To expand on what @vladimyr said, and for those who don't know, Node itself is actually on npm. So there's existing precedent for this sort of thing and it's super convenient. I chuckle a little bit when people use nvm because they're usually unaware that to use any version of Node you can simply do:

$ npx node --version
v11.6.0
$ npx node@10 --version
v10.15.0

Here's the repo that enables that: https://github.com/aredridel/node-bin-gen

How awesome would it be if you could do the same thing to access Deno? This would be a wonderful and convenient way for people to discover, learn, and begin playing around with Deno.

This wouldn't involve any functionality in Deno itself and it's not something that would be used over the entire course of developing a Deno app. Rather, it's about getting new users on board. It's basically just packaging for Deno, effectively a method of temporarily installing Deno for demo or experimentation purposes. It would probably increase adoption a fair amount.

[vladimyr]

@sholladay get-deno is not intended for one time running deno scripts. It is an installer script that sets up deno permanently on given machine. I understand appeal of:

$ npx deno script.ts

but in order for that to happen npm's target package name needs to get repurposed: #6 (comment) https://unpkg.com/deno/

I chuckle a little bit when people use nvm because they're usually unaware that to use any version of Node you can simply do:

Sorry but this is plain wrong. People don't use nvm for one time invocations but management of locally installed nodes. Also in order to exec/install node using npm/npx you already need node and npm installed...

It would probably increase adoption a fair amount.

If you say so, I don't really buy it. It is relatively easy to implement what you envisioned but making that play nicely/intuitively with DENO_DIR caching is challenging adventure...

[sholladay]

@sholladay get-deno is not intended ...

I wasn't referring to get-deno's behavior. I'm saying, "yeah, it would be great to be able to install Deno via npm, and by the way, here's another reason to do it, if Deno is on npm, then npx deno will work and people won't even need to permanently install Deno to use it." This is just a neat feature of any CLI tool on npm, and I think the benefit for Deno is particularly strong since this is a very intuitive on-ramp for potential Deno users.

Sorry but this is plain wrong. People don't use nvm for one time invocations but management of locally installed nodes

Nah, npx node@123 has completely replaced brew install node@123 or nvm use 123 for me. If you want to continue using those methods because you like how they work, fair enough. I never said they have the same semantics. But they are equally easy to use the same way - if I want to use a particular version of Node multiple times (a la nvm), then I just hit the Up arrow in my terminal or rely on Fish's excellent autocomplete. For me, npx made other ways of managing Node versions obsolete.

Also in order to exec/install node using npm/npx you already need node and npm installed

This point doesn't make sense to me. The goal of any of these systems we've been discussing is to install Node. Obviously you have to install something first since none of these things come with the operating system. So, IMO, go install some version of Node that will be your default for everyday use, it will come with npx, then when you need to, use npx to execute something with a specific version of Node other than what you have.

making that play nicely/intuitively with DENO_DIR caching is challenging adventure.

I would hope that npx deno would just be a plain old run of the deno executable with the normal environment. If you mean to say that different versions of Deno might want to do different things with DENO_DIR, well sure, maybe, but that would be a problem for any version management system for Deno, not anything specific to npx.

[MarkTiedemann]

I still believe npm install deno with a simple post_install hook running the installers from this repo would be ideal.

[vladimyr]

True that but it isn't really possible. npm install needs to install something and where would contents of package end up? In your cwd? Cluttering global node_modules with installation leftovers?
It is like installing installer which you'll run to get actual sw but leaving installer zero installed afterwards. npx might help but still you need some strong sourcery to make it work the way you envisoned...

[MarkTiedemann]

npm install needs to install something and where would contents of package end up?

npm install would install into $cwd/node_modules/deno, which would contain a package.json file, which would contain a post_install hook, which would run the installers from this repo (PowerShell on Windows, Shell on Linux or Mac) and delete $cwd/node_modules/deno.

Would that work in your opinion?

[vladimyr]

1. If you do that inside regular directory you will leave empty node_modules together with generated lockfile.
2. If you do that inside node project dir you'll gonna polute package.json and lockfile of corresponding project.

[MarkTiedemann]

1. If you do that inside regular directory you will leave empty node_modules together with generated lockfile.

Then let's check whether we're in a regular directory and remove the node_modules and lockfile afterwards. (We could also avoid the lockfile with --no-package-lock.)

2. If you do that inside node project dir you'll gonna polute package.json and lockfile of corresponding project.

We could run npm uninstall deno from the post_install hook to cleanup again. (Or add --no-save to the install command.)

Also, how about installing with --global? I don't think anyone would be mad about the global node_modules being a tiny bit more polluted...

This is looking less likely to be easy to maintain, but I think it's definitely doable.

[MarkTiedemann]

Correction: Just tried it. Clean-up of node_modules from a post_install hook is not possible. npm will somehow just re-create node_modules. So we'd have to go for --global.

npm i -g deno doesn't look so bad to me. (Perhaps even npm i -gs deno.)

[MarkTiedemann]

@vladimyr

How about this?

package.json

{
  "name": "deno",
  "version": "0.1.0",
  "scripts": {
    "postinstall": "node postinstall.js"
  }
}

postinstall.js

const child_process = require("child_process");
if (process.platform === "win32") {
  child_process.execFileSync("powershell.exe", ["-c", "[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; iwr https://deno.land/x/install/install.ps1 | iex"]);
} else {
  child_process.execSync("curl -L https://deno.land/x/install/install.sh | sh");
}

And then Node users just need run npm i -gs deno to install Deno.

[j-f1]

This would also be nice since npx has a automatic fallback feature that lets you run a command like node@4 foo.js to download/install the relevant node version, then run it.

[hayd]

The deno package name is squatted? https://www.npmjs.com/package/deno

👍 If it allowed deno foo.ts and [email protected] foo.ts that'd be really nice.

[j-f1]

Here’s npm’s dispute resolution process which allows the takeover of a squatted package name: https://www.npmjs.com/policies/disputes

[hayd]

cc @YounGoat

[hayd]

I sent an email to @YounGoat and cc'd support@npm following https://www.npmjs.com/policies/disputes, hopefully they will transfer to @ry one way or the other. 🤞

[YounGoat]

Sorry for responding so late.
I created NPM module deno a year ago and planed to offer something like real Deno and accessible in Node.js. And I am trying to achieve it. I think it is more reasonable for Node.js developers that deno is an API (require("deno")) and get-deno is a command.

[MarkTiedemann]

All right, fair point. Closing for now.

[hayd]

Maybe, but it would be much much better if this was under ry's controller rather than someone else.

@YounGoat What about calling yours require("deno-api") ?

[vladimyr]

@MarkTiedemann I might get some time in future to go back to our technical conversation but in the meantime I'll point you to following chain of tools used one by another when you hit npx node:

• https://unpkg.com/[email protected]/
• https://unpkg.com/[email protected]/
• https://unpkg.com/[email protected]/

That is how it should be done in order to not mess up with someones workspace and/or global node_modules.

---

As much as I'm not in favor of exercising strength over some squatted package name (even though I understand your good intentions) I'm also not amused when someone uses my work as part of his flawed argument. @YounGoat Let me make things clear:

1. get-deno is an installer made by me for fun & profit and isn't official or endorsed by denoland (community)
2. deno package name (being object of dispute here) was intended to host official deno installer and runner in order to support npx like scenario

There is clear difference between unofficial installer and official installer/runner so please refrain from using get-deno as an argument in this discussion.

[MarkTiedemann]

What about calling yours require("deno-api")?

@YounGoat You describe your deno package as a "[b]ridge to Deno", but I don't think "bridge" is an accurate term in this technical context. I believe it would be more accurate to describe your package as a "Deno API ported to Node", hence deno-api would be a better package name.

deno package name (being object of dispute here) was intended to host official deno installer and runner in order to support npx like scenario

This was certainly my idea when I created this issue, but then again, my ideas aren't "official". I'm not sure what @ry thinks about this.

[YounGoat]

So, the issue is not about what is the correct way of npx deno, it is about who is official ?

I agree with @vladimyr and @sholladay to run Deno once by npx deno and npx deno@<version>, it is really good idea. We may find a way to make use of package deno in both CLI and Node.js code.

However, official is not the reason. Otherwise, the world of NPM should be overturned because there are so many packages which are under status of "un-official".

[hayd]

So, the sage continues, @YounGoat refuses to cede ownership:

The request is not only about adding @ry as owner, but also about changing the usage of the deno package as I am used to. As you can see in the issue, I have expressed my opinion.
However, I have made clear explanation in README.md of latest version, and added link to the semi-official package get-deno. And, I also agree to implement npx deno in future version if possible. But I DO NOT AGREE TO GIVE UP THE OWNERSHIP OF THE deno PACKAGE.

[vladimyr]

And continues to use get-deno as argument while making his case:

However, I have made clear explanation in README.md of latest version, and added link to the semi-official package get-deno.

Except now it becomes semi-offical whatever that means...

[YounGoat]

Sorry @vladimyr, I will delete the words about get-deno in next version.

[resynth1943]

Hope this helps.

Trademarks

If you think another npm publisher is infringing your trademark, such as by > using a confusingly similar package, org, or user account name, email > [email protected] with a link to the package, org, or user account page on > https://npmjs.com. Attach a copy of your trademark registration certificate.
If we see that the user, org, or package publisher is intentionally misleading > others by misusing your registered mark without permission, we will transfer > the account, org, or package name to you. Otherwise, we will contact the > relevant user and ask them to clear up any confusion with changes to their user > account page, or page, or package README file.

When to use this process

This process is an excellent way to:

• Adopt an "abandoned" package
• Adopt a package created from your project, published by someone else
• Report "squatting"
• Report a deliberately misleading or confusing package name

[orta]

Just popping by to say this setup was kinda how I was hoping I could install deno as a sneaky script runner in the devDependencies section of the typescript website.

Contributors could yarn install then most of my build scripts would be yarn deno path/to/script.ts.

[kevinkassimo]

Whoa, did not realize this thread exists...

Worth noting a similar event happened when worker_threads of Node tries to take the worker name: see blake-regalia/worker.js#1

Personally my attitude is okay with @YounGoat keeping the deno package name on NPM. I don't think a fight over control is the way we should be heading. Based on my observation, I trust @YounGoat created the package with no ill will, and I believe it is also a right for him to keep it (just like early domain registering that does not violate laws). @YounGoat 's creation of this package early on with non-trivial code contribution also shows that he did want to help the Deno community, and I am actually very happy about it.

Over potential conflicts like this one, I believe we should demonstrate a welcoming attitude to anyone who provides any means of help to the community. Animosity is not helpful after all.

(don't open unless you are okay with seeing some harsh words)

A good friend of mine has been warning me about actively participating with community discussions saying quote "JS community is a bunch of 'axx-xxxxs'", and I am very sad to have seen quite some toxic dramas in recent years. I really hope the we can avoid creating more of such situations and try creating a better atmosphere to prove that my friend is wrong.

I have also just registered https://www.npmjs.com/org/deno_land in case we need an org account to host packages at some point. I will invite other contributors if somehow this is decided to be the account we want to host stuff with.

[hayd]

For a historical note, I began the npm dispute process when there was zero code in YounGoat's repo and there was also no response via email or on GitHub. Since then they responded and ry told me to drop it.

Now it's very different, there is an actual meaningful project that's being regularly updated. I still think it's silly not to be under ry's control but whatever. The matter is closed.

[vladimyr]

I don't think a fight over control is the way we should be heading.

I completely agree.

Based on my observation, I trust @YounGoat created the package with no ill will, and I believe it is also a right for him to keep it (just like early domain registering that does not violate laws).

It surely is legally right for they to keep it and push hard to stay that way. Is it morally right is a different type of story that heavily depends on your perspective and set of standards. Also, life would be too simple if all actions could be sorted into good and bad will buckets. Seeking (collateral) fame through package name squatting doesn't really fit any of those. Welcome to the gray zone. 😉

@YounGoat 's creation of this package early on with non-trivial code contribution also shows that he did want to help the Deno community, and I am actually very happy about it.

This was already disputed by @hayd and can be easily verified by going through git history. I think you went too far with that statement because not everyone that releases something with deno in its name is trying to help the community. That doesn't mean they are trying to do any harm but every action isn't helpful per se, it just boosts public interest.

Over potential conflicts like this one, I believe we should demonstrate a welcoming attitude to anyone who provides any means of help to the community. Animosity is not helpful after all.

I agree with your point about animosity but let's not forget that relationships go both ways. Both sides should have an initial welcoming attitude that eventually gets adjusted according to direction and tone of the conversation and I'm not sure that is what happened here.

This brings me to @hayd's comment #6 (comment)... His comment edit history is pure gold 😉 Because these days everyone became so obsessed with form over substance and because I'm old enough that I don't give a #%& here comes the ugly version:

1. @hayd's comment Install via npm #6 (comment) had bit aggressive tone at the end which is understandable because they decided to ignore the issue of name dispute for a half year already and completely ignored @MarkTiedemann's polite request Transfer ownership to Deno project YounGoat/nodejs.deno#1

2. After a long period of silence, they came back with a flawed argument that is partially built upon my work. Conversation continues in what I would call weird and aggressive tone. (I wholeheartedly agree with @hayd's redacted comment and it didn't sound like a language issue to me.) And when you act like one you'll most probably get a knee-jerk reaction...

3. I believe everyone silently agreed to let it go because there is no point in exercising strength over it. As a consequence thread naturally faded away but gets revived by random visitors. Not that I'm a big fan of it but maybe it is for the best to lock it down.

4. This shouldn't be treated as a sign of potential flaws in the community because nobody did anything wrong here and that is coming from my outsider perspective. I'm not officially part of a community but I feel more than welcome and fail to see any reasons why shouldn't.

5. Endorsing people is nice but let's not stretch the definition of a meaningful project. It is their playground with 2 contributors and 12 commits and certainly doesn't look promising. It lacks many ingredients successful node packages contain. You can change that if you want, through contributions, but until that happens it is still just a toy grade thing.

6. Of course, it is ridiculous it is not under not ry's but community control but they simply can't afford losing it - go figure out why 😉

[vladimyr]

Contributors could yarn install then most of my build scripts would be yarn deno path/to/script.ts.

@orta FWIW different npm packages can contain equally named binaries so it can be resolved by publishing @denoland/deno package with deno binary inside. It is however easier said than done due to reasons explained earlier, see #6 (comment)

[j-f1]

Maybe we could name the package deno-bin a la flow-bin?

[vladimyr]

Just please don't build it the same way: https://npmfs.com/package/flow-bin/0.113.0/ cause it is pretty weird to pay download penalty for binaries you can't and won't ever use: https://packagephobia.now.sh/result?p=flow-bin

[airtonix]

you should just use asdf tbh.

edit... I can't believe you people think it's a good idea to install a language engine with another language engines package manager... -_-

Seriously, if you think nvm is awesome... throw it out and start using asdf. literally everywhere you think you have to use nvm, you can replace it with asdf.

[MirKml]

just for notice - deno-bin npm package - https://www.npmjs.com/package/deno-bin exists for a long time. It works good enough and it's maintained by one of deno core members (I think).

[dsherret]

We finally got ownership of the deno package. Follow denoland/deno#27341 for updates.

[dsherret]

Deno is now available on npm: https://www.npmjs.com/package/deno