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

Suggestion: Use Vale for styling? #19687

Open
wants to merge 2 commits into
base: 5.4
Choose a base branch
from
Open

Suggestion: Use Vale for styling? #19687

wants to merge 2 commits into from

Conversation

fabpot
Copy link
Member

@fabpot fabpot commented Mar 18, 2024

https://vale.sh/ is a nice tool. I'm wondering if we could adopt it for Symfony.
I've configured it very quickly to see if it could be useful. We would need to adapt the rules to our needs of course.
WDYT?

@carsonbot carsonbot added this to the 5.4 milestone Mar 18, 2024
@javiereguiluz
Copy link
Member

javiereguiluz commented Mar 18, 2024

I haven't checked all rules .... but it seems that after merging this, we couldn't use words like backend (.vale/Microsoft/Avoid.yml) and expressions like e.g. or i.e. (.vale/Microsoft/Foreign.yml) which are very common in our docs.

My opinion is that, even if linting is always nice, if we add this to CI checks it could be too much linting, which creates friction for contributors and demoralizes maintainers. If it's used as a command run from time to time to fix some of the issues and ignore all the false positives, then it could be a useful tool.

@fabpot
Copy link
Member Author

fabpot commented Mar 18, 2024

I haven't checked all rules .... but it seems that after merging this, we couldn't use words like backend (.vale/Microsoft/Avoid.yml) and expressions like e.g. or i.e. (.vale/Microsoft/Foreign.yml) which are very common in our docs.

My opinion is that, even if linting is always nice, if we add this to CI checks it could be too much linting, which creates friction for contributors and demoralizes maintainers. If it's used as a command run from time to time to fix some of the issues and ignore all the false positives, then it could be a useful tool.

It's all configurable.

- USB
- UTF
- XML
- XSS
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think XSS should probably be removed from the allow list, ensuring we actually have the actual name of the vulnerability mentioned instead of only the abbreviation.

@wouterj
Copy link
Member

wouterj commented Apr 20, 2024

Never heard of Vale. I think this is very interesting!

As a start, we can include it for usage as a local linter (like we also did with the .alexrc config). It seems to have some false-positives and errors that are more "are you sure this is what you want", so enforcing it in CI might be a step to far as of now.

Some of the rules can replace rules that exists in DOCtor-RST. Some of the rule sets also give a nice insight in some "best practices" of writing English sentences that we didn't use in the docs yet.

I've adopted the config a bit to match our style (e.g. using "e.g." and our Chicago-like title case) and linted all guides in the "quick tour", "create your own framework" and "getting started" section of the docs: ac3b26b In general, I feel like this can be a useful tool.

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

Successfully merging this pull request may close these issues.

None yet

5 participants