-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable BYONM by default for Deno 2 #23151
Comments
I'm not sure if enabling multiple config files in the project is a good approch. I think it would be more natural to port one dependency than one source tree at the time if it's even feasible. Like if there is package.json present, manage stated dependencies there in node_modules and the rest in Deno way defaulting to resolve import specifiers in Node way so that the user could migrate one dependency at the time by deleting corresponding dependency from package.json and making needed source changes? |
When `DENO_FUTURE=1` env var is present, then BYONM ("bring your own node_modules") is enabled by default. That means that is there's a `package.json` present, users are expected to explicitly install dependencies from that file. Towards #23151
When `DENO_FUTURE=1` env var is present, then BYONM ("bring your own node_modules") is enabled by default. That means that is there's a `package.json` present, users are expected to explicitly install dependencies from that file. Towards #23151
just an observation, but it seems like there is a push towards corepack compatibility in the node ecosystem, which might be worth having that in mind here. Relevant links |
What is the current status regardigng deno deploy and this feature? What I already tried:
I found a solution that works for me: In addition to the config above, I write the npm specifiers into the import map, as part of a script that runs after installing any dependency using But I'm still curios if there is a better solution. |
Summary: denoland/deno#23151 Use byonm so we don't have to mess around with node modules otherwise. Test Plan:
Summary: denoland/deno#23151 Use byonm so we don't have to mess around with node modules otherwise. Test Plan:
Summary: denoland/deno#23151 Use byonm so we don't have to mess around with node modules otherwise. Test Plan:
Summary: denoland/deno#23151 Use byonm so we don't have to mess around with node modules otherwise. Test Plan:
Summary: denoland/deno#23151 Use byonm so we don't have to mess around with node modules otherwise. Test Plan:
I think we can close this one now. |
For Deno 2 we want to enable BYONM (bring your own node modules) by default as we found that it greatly increases compatibility with multiple existing frameworks - eg. it makes frameworks like Solid or Next.js work OOTB in Deno.
Additional advantage is that it makes it much easier to explain dependency management in Deno, when running Node.js projects in Deno or migrating from Node.js to Deno. There will be 3 "modes":
jsr:
/npm:
/http:
/https:
specifiers, fully managed by Deno with autoinstallation. This is the current default.--unstable-byonm
mode - the npm dependencies are managed by a package manager (currently npm/yarn/pnpm). We will add proper support withdeno add
/deno install
that will create a compatiblenode_modules/
directory structure. This is the most compatible way to run multiple popular frameworksdeno.json
file in that directory.Mode 3 requires more work by providing helpful errors messages guiding towards proper solution.
Before we enable BYONM by default, we're gonna make it default when
DENO_FUTURE=1
env var is present so that users can start using it immediately and provide feedback.This change will allow us to limit some of internal complexity by removing one of the npm resolvers we have.
The text was updated successfully, but these errors were encountered: