Closed
Description
Summary:
Add support for a pre-commit
hook that uses this linter to validate the Browserslist configuration during the commit process. This ensures that only valid configurations are committed, reducing build-time issues and improving browser compatibility.
Why is this feature needed?
- Browserslist configuration plays a critical role in determining browser compatibility for tools like Babel, Autoprefixer, and others.
- Invalid configurations can lead to unexpected runtime behaviors, missed polyfills, or broken CSS prefixes.
- Developers might inadvertently commit invalid .browserslistrc files or incorrect browserslist keys in package.json.
- A pre-commit hook ensures validation happens early in the development workflow, reducing feedback loops and saving debugging time.
How would this feature work?
The hook would rely on the pre-commit
framework and:
- Automatically validate Browserslist configuration if:
- A
.browserslistrc
file is present, or - A
browserslist
key exists in package.json.
- A
- Use the
browserslist-linter
npm package to perform the validation. - Run during the
pre-commit
phase viapre-commit
framework integration.
Proposed Implementation:
Provide a pre-commit-hooks.yaml file as part of this repository.
Include documentation for adding the hook to a .pre-commit-config.yaml file.
Example configuration:
- id: browserslist-lint
name: Validate Browserslist Configuration
entry: npx browserslist-linter
language: node
files: ^(\.browserslistrc|package\.json)$
pass_filenames: false
always_run: false
description: Validate Browserslist configuration using browserslist-linter.
Benefits:
- Prevents invalid configurations from entering the codebase.
- Enhances team productivity by catching issues early.
- Improves adoption of browserslist-linter by integrating it seamlessly into workflows.
Request:
I’d love to contribute this feature if it aligns with your vision for the project. I have created a Pull Request #8 with the proposed changes as well. Please let me know if I can contribute in any other capacity.
Metadata
Metadata
Assignees
Labels
No labels