FYI, you may also try https://esm.sh/{{npm_package}}@{{version}}, that is self-hostable, and support types with zero config.
For private module, you can combine with verdaccio, and docker to save your time.
This workflow is network base. Easy to use/cache in container.

@loynoir off-topic, but I'd like to mention that esm.sh is developed by a Deno team member. Better support for npm specifiers is going to eliminate the need to resort to third-party solutions like such.

@kidonng I don't want to repeat what was said in #13703, but esm.sh absolutely has it's place in the deno ecosystem. Writing browser compatible code is a goal we should strive for when we can, and esm.sh does it perfectly imo

Just a question regarding import.meta.resolve. How will this work if I pass an npm specifier? Will it resolve to the npm registry URL?

@deckchairlabs let's discuss in #16089 -- probably returns the cached path

Is there any plan to support directly running code meant for node?

For example, I'm trying to run mocha.js which targets commonjs and uses require statements. Is this supported? Is there a way to use an npm specifier to import from a local file?

Any reason why https://github.com/denoland/deno/blob/main/cli/npm/cache.rs#L222 isn't being tracked here?

@tuhanayim I added it just now. Curious what package you ran into that wasn't all lowercase?

@dsherret @commitlint/cli. I don't think it's a lower/uppercase mismatch though, it just panics there.

Ok, it's because of a module named JSONStream. Dependency flow: @commitlint/cli > @commitlint/lint > @commitlint/parse > conventional-commits-parser > JSONStream

When I using bitcoinjs-lib and bip32 with deno npm specifiers.

(Skipped some code, only showing the related)

import bitcoin from 'npm:bitcoinjs-lib'
import { BIP32Factory as bip32 } from 'npm:bip32'
import bip39 from 'npm:bip39'
import * as ecc from 'npm:tiny-secp256k1'

let mnemonic = 'mnemonic'
let seed = bip39.mnemonicToSeedSync(mnemonic)
let root = bip32(ecc).fromSeed(seed)

This code throw error from fromSeed() function which is using hmac SHA512
"error: Uncaught Error: Not implemented: crypto.Hmac"

Because of this, I can't using bitcoinjs-lib with deno.
I temporarily using node.js instead until deno implemented crypto.Hmac.

Is there any work planned for the task automatic acquisition of @types package for type checking? I think this is the cause of TSX warnings about JSX.IntrinsicElements in React, if the jsxImportSource is configured to "npm:react" (it doesn't happen with npm:preact).

@Bzvwf16WSDKoSZd8 there is an open issue here denoland/std#2557 also there is #16107

Is there any plan to support directly running code meant for node?

@MarkBennett not at the moment. That would mean supporting applications written with CommonJS in Deno and having Node globals, which we want to avoid. It would be ideal for Deno to remain ESM only. We probably will support specifiers like node:fs in the future though.

I think this is the cause of TSX warnings about JSX.IntrinsicElements in React, if the jsxImportSource is configured to "npm:react" (it doesn't happen with npm:preact).

@oscarotero would you be able to open an issue for this one? Sounds like there's a pain point here. Thanks.

@dsherret Done! #16653

not at the moment. That would mean supporting applications written with CommonJS in Deno and having Node globals, which we want to avoid. It would be ideal for Deno to remain ESM only. We probably will support specifiers like node:fs in the future though.

@dsherret I agree. To maintain consistency with the browser code, Deno should only keep the ESM.

@tuhanayim non-all lowercase package name support will be in 1.28.1 (releasing later today) #16669

@tuhanayim non-all lowercase package name support will be in 1.28.1 (releasing later today) #16669

That was quick! Thanks 🙏

Is compatibility with NextJS planned / being tracked?

@cmoog that's something we're looking into, but I recommend opening an issue about anything not working.

If anyone has a question or issue with npm compatibility I recommend opening an issue so that we can track everything individually within issues. That also helps make everything more searchable for others. Going to lock this issue to encourage that.

Going to close this one as it doesn't seem worth tracking anymore. deno compile and vendor support will come in 1.34.