npm specifiers roadmap

[dsherret]

• Private registry / Configure npm registry for module download #16105
• Post install scripts Support for install scripts (ex. "postinstall") for "npm:" specifiers with global node modules #16164
• LSP registry completions lsp: npm registry completions on module specifiers #15811
• npm: automatic acquisition of @types package for type checking #20455
• lsp: should work with local node_modules directory #16373
• Local node_modules folder should use hard links instead of copying from global cache when on the same partition #16062
• deno compile support (deno compile cannot resolve npm modules #16632)
• deno vendor support (feat(vendor): support for npm specifiers #19186)
• optionalDependencies (ex. esbuild)
• repl support npm imports don't work in repl #16088
• cache bust npm specifiers more aggressively Cache bust npm specifiers more aggressively #16901
• Support non-all lowercase package names (ex. JSON vs json) (1.28.1)
• deno install support (1.28.1)
• peerDependencies (feat(unstable/npm): support peer dependencies #16561) (1.27.2)
  • for local node_modules: https://pnpm.io/how-peers-are-resolved
• deno info support (1.27.1)
• Lockfile support Lockfile support for experimental npm specifiers #15696 (1.27.0)
• Typescript support (1.27.0)
  • LSP
  • Figure out how to have node globals not conflict with deno globals
  • @deno-types support
• Node API (n-api) support feat(npm): implement Node API #13633 (1.27.0)
• Nice error if someone does "npm:react-dom/[email protected]" instead of "npm:[email protected]/server" (fix(npm): better error is version is specified after subpath #16131)
• Local node_modules folder Add a flag to symlink "node_modules/" directory to CWD #15822 feat(npm): add flag for creating and resolving npm packages to a local node_modules folder #15971 - pnpm-like node_modules folder
  • Nice to have: Local node_modules - Use junctions instead of symlinks on Windows #16006
• --reload=npm: support feat(npm): add support for --reload=npm: and --reload=npm:<package> #15972
• deno cache npm:<package> (feat(unstable): add support for npm specifier cli arguments for 'deno cache' #16141)
• Cache cjs export and esm global analysis #15748
• deno pack (prev. bundle) support

[loynoir]

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.

[kidonng]

@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.

[AnInternetTroll]

@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

[deckchairlabs]

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?

[dsherret]

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

[MarkBennett]

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?

[catuhana]

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

[dsherret]

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

[catuhana]

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

[catuhana]

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

[h76oeI6pMxU9g4p8aCpc6Q]

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.

[oscarotero]

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).

[dsherret]

@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.

[oscarotero]

@dsherret Done! #16653

[h76oeI6pMxU9g4p8aCpc6Q]

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.

[dsherret]

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

[catuhana]

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

That was quick! Thanks 🙏

[cmoog]

Is compatibility with NextJS planned / being tracked?

[dsherret]

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

[dsherret]

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.

[dsherret]

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