Skip to content
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

Closed
bartlomieju opened this issue Mar 31, 2024 · 4 comments
Closed

Enable BYONM by default for Deno 2 #23151

bartlomieju opened this issue Mar 31, 2024 · 4 comments

Comments

@bartlomieju
Copy link
Member

bartlomieju commented Mar 31, 2024

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":

  1. Deno-first - you can use jsr:/npm:/http:/https: specifiers, fully managed by Deno with autoinstallation. This is the current default.
  2. Node-first - this is the current --unstable-byonm mode - the npm dependencies are managed by a package manager (currently npm/yarn/pnpm). We will add proper support with deno add/deno install that will create a compatible node_modules/ directory structure. This is the most compatible way to run multiple popular frameworks
  3. Mixed/migration mode - you can run an existing Node.js project and start migrating it gradually to Deno, by mixing Node-first with Deno-first dependency management - eg. you can only migrate a "tools/" directory to be Deno first, by delimiting certain directory by putting deno.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.

@kuchta
Copy link

kuchta commented Apr 2, 2024

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?

bartlomieju added a commit that referenced this issue Apr 2, 2024
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
satyarohith pushed a commit that referenced this issue Apr 11, 2024
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
@birkskyum
Copy link
Contributor

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

@karfau
Copy link

karfau commented May 2, 2024

What is the current status regardigng deno deploy and this feature?
Can I only use this locally? Can I add a build script or use deployctl in some way that this would be "resolved before deploying"?

What I already tried:

  • setting {"unstable": ["byonm"]} in deno.json

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 pnpm (part of prepare script). This way I can use "bare specifiers" inside the code.

But I'm still curios if there is a better solution.

@bartlomieju bartlomieju removed their assignment Aug 27, 2024
randallb added a commit to bolt-foundry/bolt-foundry that referenced this issue Sep 3, 2024
Summary:

denoland/deno#23151

Use byonm so we don't have to mess around with node modules otherwise.

Test Plan:
randallb added a commit to bolt-foundry/bolt-foundry that referenced this issue Sep 3, 2024
Summary:

denoland/deno#23151

Use byonm so we don't have to mess around with node modules otherwise.

Test Plan:
randallb added a commit to bolt-foundry/bolt-foundry that referenced this issue Sep 3, 2024
Summary:

denoland/deno#23151

Use byonm so we don't have to mess around with node modules otherwise.

Test Plan:
randallb added a commit to bolt-foundry/bolt-foundry that referenced this issue Sep 3, 2024
Summary:

denoland/deno#23151

Use byonm so we don't have to mess around with node modules otherwise.

Test Plan:
randallb added a commit to bolt-foundry/bolt-foundry that referenced this issue Sep 3, 2024
Summary:

denoland/deno#23151

Use byonm so we don't have to mess around with node modules otherwise.

Test Plan:
@dsherret
Copy link
Member

I think we can close this one now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants