Move to monorepo

[ronag]

This would solve...

Currently the undici package is quite heavy with a lot of stuff that you might not need, e.g. web api. Would be good to separate undici "core" into its own package.

The implementation should look like...

Use pnpm

[metcoder95]

I think @Ethan-Arrowood was managing this idea for a while, after the split of undici-types

[Ethan-Arrowood]

There's some old threads about monorepo ideas. Happy to revisit

[mcollina]

I think it's inevitable that we adopt a monorepo at this point, this project has grown too big, and there are separate subsystems that could be used separately.

[Ethan-Arrowood]

Use pnpm

This is also my preference. Does anyone feel extra-strongly about using npm?

pnpm is now included in corepack so it should be very easy for everyone to use it without any additional install or set up (minus a corepack enable call).

[Ethan-Arrowood]

I will also start by experimenting with npm workspaces to start. They've supposedly come along way so maybe its worth trying again.

[mcollina]

I've not been able to make npm workspace work in any reasonable way for OSS development

I think the most useful part would be if somebody could figure out how to set it up with changesets so that we could ship independent versions of the packages. Alternatively, they will all have the same version.

[Ethan-Arrowood]

I have experience with changesets. Do you want me to try npm+changesets or go straight to pnpm+changesets?

[Ethan-Arrowood]

Rough plan:

1. Create PR that moves everything into packages/undici and documentation
   • No code will split up just yet
   • CI should run as normal
   • Docs site should work as normal
   • Other tooling should continue to work (build, commit hooks, etc.), and run from root as normal
   • This should only introduce npm workspaces. Changesets should not be required.
   • Even though the code will exist in packages/undici directory, the package should still be named and published as undici (for now).
   • (In nodejs/node) Update Node.js -> Undici vendor process

Step 1 is simply the first step in migrating to a monorepo. This will reduce impact on contributors and should not disrupt development.

2. Code split (incremental)
   • Create new packages packages/core, packages/fetch, and packages/types
   • Start publishing packages as @undici/core, @undici/fetch, and @undici/types
   • Retain packages/undici as undici and make it roll-up and export all of the other packages
   • Introduce changesets for version and publishing management.
   • (Optional) Move linting and formatting to root

Step 2 serves as an incremental step to a true monorepo organization. By retaining undici package we don't have to affect Node.js or users. Everything will appear as normal.

3. Migrate Node.js from undici to @undici/fetch

   • Make necessary change in nodejs/node to vendor @undici/fetch instead of undici

4. More code splitting!

   • Intentionally not-well-defined at this time, consider other parts of Undici that we can split out into its own separate packages.

[mcollina]

I'm +1

[metcoder95]

LGTM 🚀

[Ethan-Arrowood]

I'll have a PR up for step 1 very soon. I'd like to land #2766 first as that will help simplify things.

[mcollina]

My experience with npm workspaces is that they are not fit for purpose. Specifically, they are missing the workspace protocol, https://pnpm.io/workspaces#referencing-workspace-packages-through-aliases, which makes it impossible to maintain an OSS library without it. (Or I couldn’t figure out how to handle versioning).

---

@KhafraDev wdyt?

[Ethan-Arrowood]

I've found more success where versions are updated by a tool such as changesets. That said, switching to pnpm has other great benefits -- and everyone can do it since it's supported in corepack. Ill make sure to present options for us to consider

[Uzlopak]

I dont like monorepos. They make managing code complicated. I would rather have one package released on npm with everything than having to manage many packages where each package has different versions.