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.

[danielroe]

I've started work on https://github.com/danielroe/unplugin-purge-polyfills, which aims to do exactly the bundler piece. (I wasn't aware you might consider doing that inside nolyfill or I would have directly opened it here.)

I would love to figure out how to collaborate on the build plugin piece of this. For example, if we could polyfill/replace more code in unplugin-purge-polyfills using the nolyfill codegen that would be amazing 🙏

[SukkaW]

I've started work on https://github.com/danielroe/unplugin-purge-polyfills, which aims to do exactly the bundler piece. (I wasn't aware you might consider doing that inside nolyfill or I would have directly opened it here.)

A bundler integration would be great! I have not gotten my hands on that yet and I am glad you are creating one!

Currently, nolyfill hasn't provided a way for plugins to read the metadata of nolyfill (E.g. replace-able packages list, existing nolyfill replacement list, the version of the packages). @wojtekmaj implements his yarn-plugin-nolyfill by manually syncing the list.

Do you have any suggestions for the metadata formats?

[justinfagnani]

It would be really nice to have a diagnostic mode that visualizes the npm dependency tree a little like npm ls, but labels which packages can be replaced by plain JS, and how much disk and bundle space (via bundlephobia?) they take up.

[SukkaW]

It would be really nice to have a diagnostic mode that visualizes the npm dependency tree a little like npm ls

That's nice to have, but evaluating the dependency graph is a very tedious job though.

and how much disk and bundle space (via bundlephobia?) they take up.

bundlephobia outputs after-bundled size which doesn't reflect the real-world non-bundled installation (which IMHO is more important). packagephobia is not that stable and often returns 500 errors on large packages.

See also the previous attempt: #13