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

[FEATURE]: Provide guidance around pinning browserslist and caniuse-db, to avoid unintended lint errors #6

Open
fpapado opened this issue Oct 29, 2024 · 0 comments

Comments

@fpapado
Copy link
Collaborator

fpapado commented Oct 29, 2024

Relevant package @woltapp/eslint-plugin-browserbug, @wotlapp/stylelint-plugin-browserbug.

Is your feature request related to a problem? Please describe.

  1. Configure a browserbug linting rule as 'error'
  2. Specify a browser that is the "latest" at the time of writing, such as @browserbug chrome lower-than 131
  3. A different installation (perhaps a different PR) changes the lockfile, to resolve a relatively older version of browserslist or caniuse-db
  4. The linter will show an error, because that latest version is no longer recognised 😱

A similar issue can happen if you accidentally update browerslist or caniuse-db, and the specified version falls out of the supported range.

The core issue here is not an intentional update to browserslist (after all, it is the intent of this library to prompt you to delete things), but rather accidental updates due to the lockfile changing.

Describe the solution you'd like

To avoid this issue, we can do a few things:

  • Configure a setting to opt-in or opt-out of unknown version bugs
  • Perhaps we can downgrade unknown versions to a warning, by default?
  • This only accounts for only one of the problems, but this is the more annoying one. A "latest" browserslist is always the correct one, given that time marches on (browser releases happen, and statistics change 😅 )
  • Write documentation on how to pin caniuse-db and/or browserslist. This likely would be via a package manager's overrides field.

Describe alternatives you've considered

Doing nothing is also an option, and prompting people to figure out why the resolved version changed. However, this can be non-obvious, given transitive dependencies, deduplication and other resolution rules.

Additional context

My gut feeling is to start with explicit documentation, and to consult what browserslist and/or caniuse-db advise.

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

1 participant