A few ideas

[antfu]

First, this is a very interesting idea, and I see a lot of potential in it that would benefit the entire Node ecosystem. Here I have a few suggestions that just came out of my mind, that I think might help the community to grow.

Code Orangizing Wise

• It might be better to separate the packages/ into two directories, for example, /packages and /nolyfills to separate the source of tooling like /packages/cli and the generated packages. This would help contributors to understand the structure and contribute more easily. - refactor: reorganize packages #22
• It would be better if the versions of each package were standalone and bumped only when needed. Since a lot of them are simple packages that aren't going to change often. So usually, ppl don't have to update every nolyfills every time you do the release. I imagine this can be done by the script easily - feat: standalone version for each package #23
• Maybe there would be a better format than the current create.cjs, as the indentation is off and there is no syntax highlight. I consider it might be hard to maintain in the long term.
  • Maybe a huge .cjs file that is separated with magic comments. This way, we could also utilize formatters and linters to help maintain them.

For the points listed above, I am happy to help and send PRs if you think they are good ideas.

Feature Wise

• To me, I think the ultimate solution for such "one-line packages" situation would be to avoid those packages at all. A few immature ideas
  • For pnpm, we may use the .pnpmfile.cjs manipulate the dependents from the database in [Feature Request] Programmatic usage (JavaScript SDK) #20
  • Maybe we could dynamically replace the require('xxx') from the dependent and generate patches atomically
  • If there are community-made "modern rewrite" (for rather more complex projects), maybe they can be included (or extensible) in the nolyfill database and replaced together while leaving the complexity outside of nolyfill
• It would be nice to print which packages are relying on the packages we patched, similar to pnpm -r why xxx but with a more unified display and programmatic APIs
• With the SDK/DB, I guess we might also have a build plugin. So that the build tools can throw warning when those packages get detected, and auto patch it in the build (even with ESM directly?), so they could also help with the frontend bundles
  • Fetch data directly from CDN

---

I am looking forward to contributing and seeing the community grow. I will try to update this issue whenever I have new ideas.