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

[RFC] Improve peer dependency handling #249

Open
reiv opened this issue Apr 27, 2024 · 1 comment
Open

[RFC] Improve peer dependency handling #249

reiv opened this issue Apr 27, 2024 · 1 comment

Comments

@reiv
Copy link
Member

reiv commented Apr 27, 2024

Currently the package pulls in dependencies which might not always be required (e.g. React). This makes the setup very easy right now but could bloat in the future.

Approach 1:

  • Mark dependencies like eslint-plugin-react as peer dependencies
  • Mark peer dependencies as optional if they aren't strictly required in all cases
  • Install peer dependencies as part of the setup script (depending on the presets used)
  • No monorepo required
  • Plugins leak into the project's package.json (like in the old days)

Approach 2:

  • Split up into separate packages with (non-peer) dependencies (e.g. linting-preset-react)
  • Setup script assembles these packages
  • Monorepo
  • Plugins remain encapsulated

I think the second approach would also benefit projects which are themselves monorepos (microfrontends anyone?). But versioning everything might become a bit of a pain point.

@mvarendorff2
Copy link
Member

My gutfeeling says going with approach 2 is the long-term sane approach. For versioning, we could use changesets which I am already using to version the codegen-plugins. They also have a GitHub action we can just throw at the whole thing to auto-detect changesets and take charge on updating changelogs and versioning everything.

I am also unsure if the effort is really necessary at this time because the plugins are relatively small and don't contribute too much bloat to the node_modules compared to other packages ususally present in the project but I might be mistaken.

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

No branches or pull requests

2 participants