NPM packages are incorrectly assumed to have downloaded into the registry.npmjs.org cache

[jakesgordon]

The esbuild_deno_loader assumes that NPM packages are in a deno cache sub folder named registry.npmjs.org - (see hard coded value here)

Unfortunately this assumption breaks now that Deno supports private NPM packages via an .npmrc file (see release notes) where the registry name is likely to be different (e.g. npm.pkg.github.com)

Are there any plans to support alternative registries, or any obvious workarounds that might make this work?

Background

I have a private NPM package in the GitHub NPM registry so I use an .npmrc file that looks like this...

registry=https://registry.npmjs.org/
MY-PACKAGE:registry=https://npm.pkg.github.com/
//npm.pkg.github.com/:_authToken=${NPM_TOKEN}

A regular Deno import { foo } from "MY-PACKAGE works fine, and Deno downloads the package into ~/.cache/deno/npm/npm.pkg.github.com/MY-PACKAGE

... but if I try to bundle it with the esbuild_deno_loader it throws an error because it assumes the source is in ~/.cache/deno/npm/registry.npmjs.org/MY-PACKAGE

✘ [ERROR] No such file or directory (os error 2): stat '/home/jake/.cache/deno/npm/registry.npmjs.org/@MY-PACKAGE/0.0.1' [plugin deno-loader]

[gavares]

@lucacasonato - I just hit the same issue only to find that you made a fix 5 days ago. I was trying to find an RC that might have your change in place. I've tried 0.11.0-rc.1 but I think that still has the same problem. Is there another RC I might be able to use?

[lucacasonato]

Unfortunately not yet. There is a paired change in the Deno CLI that needs to land first.

[lucacasonato]

In the next release of this library this will start working if you use a canary release of Deno. It should be available in the next regular deno patch release.

[jakesgordon]

Fantastic. Thank you!

[lucacasonato]

This is now working in Deno 2.0.2