[ferriswil]

I've enjoyed trying to use Deno for a small new service at $WORK. Sadly had to give up and retreat back to Node due to missing support for private NPM repositories and lack of Datadog tracing support.

Their compatibility is getting better and better, so I'm confident Deno will eventually be a clear "better Node".

[Hamcha]

One use case where pure Deno works for me is shell scripts. Writing them in Deno is quite pleasant and they usually don't need many dependencies. Plus you can always host then and just "deno run <url>" from any machine that has it. It used to be a problem that you had to know permissions ahead of time but now they interactively ask you for it which makes the scary "-A" flag much less needed.

[JimDabell]

You can also compile them to standalone executables easily with `deno compile`.

[satvikpendem]

I wonder how that works, do they ship the entire Deno runtime with the executable à la Electron?

[Hamcha]

Yes, a `console.log()` compiles to a 78.46MiB .exe

[satvikpendem]

Wow, sounds like I'll stick with Rust.

[wirelesspotat]

What was the issue you encountered with private registries on Deno? Based on Deno's docs, it looks like they're supported[0]

[0] https://docs.deno.com/runtime/manual/basics/modules/private

[ferriswil]

What I'm looking for is the equivalent of this .npmrc contents to access an NPM module on Github Packages:

  //npm.pkg.github.com/:_authToken=${AUTH_TOKEN}
  @myEmployer:registry=https://npm.pkg.github.com/

My impression is that the document you've linked isn't related to their NPM compatibility, but perhaps I need to look more into it.

[ferriswil]

Here is the relevant Github issue with a better explanation:

https://github.com/denoland/deno/issues/16105

[norman784]

Now that there is also bun, both javascript tooling/runtime ecosystem will improve faster, now there are 3 competing mainstream runtimes (but as now the only one that is production ready imho is node)