feat: Add ignorePattern to no-v-html
#2857
Conversation
🦋 Changeset detectedLatest commit: 18fc869 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
This allows configuring the rule such that certain variables are allowed in v-html=. For instance, we would like to allowlist variables named “*Html” (as in the test), where the name already marks them as containing safe HTML that’s expected to be used with v-html=.
lucaswerkmeister
force-pushed
the
no-v-html-ignorePattern
branch
from
522c93a to
c98c01e
Compare
Huh, apparently |
* Update Wikibase from branch 'master'
to 47afac06a696e77eac205da4c5df7ce3fdd07e87
- Disable vue/no-v-html rule in wbui2025 directory
The v-html directive is part of our expected workflow for reusing
server-rendered HTML (property links, snak values; see the upcoming ADR
of T399832). As such, this eslint rule is not currently useful for us.
If eslint adds the ignorePattern (or similar) option suggested in [1],
then we may later use it again (but note that this will require us to
upgrade to the latest version of eslint-plugin-vue first).
[1]: vuejs/eslint-plugin-vue#2857
Change-Id: I8926d09a67927dc36b0bd5cfdb3e5c6a7256842e
The v-html directive is part of our expected workflow for reusing server-rendered HTML (property links, snak values; see the upcoming ADR of T399832). As such, this eslint rule is not currently useful for us. If eslint adds the ignorePattern (or similar) option suggested in [1], then we may later use it again (but note that this will require us to upgrade to the latest version of eslint-plugin-vue first). [1]: vuejs/eslint-plugin-vue#2857 Change-Id: I8926d09a67927dc36b0bd5cfdb3e5c6a7256842e
Co-authored-by: Flo Edelmann <[email protected]>
|
(I’ve been adding commits under the assumption that you’ll squash them on merge and throw away the intermediate commit messages – let me know if you’d like the Git history cleaned up into a version that would be suitable for a merge commit ^^) |
There was a problem hiding this comment.
Pull Request Overview
This PR adds an ignorePattern configuration option to the no-v-html ESLint rule, allowing developers to allowlist variables with names matching a specific pattern for use with the v-html directive. This enables safer use of v-html when variables are intentionally named to indicate they contain safe HTML content.
- Adds
ignorePatternoption to rule schema that accepts a regex pattern string - Implements logic to skip reporting violations when variable names match the configured pattern
- Updates documentation with configuration examples and usage guidelines
Reviewed Changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| lib/rules/no-v-html.js | Implements the ignorePattern option with regex matching logic |
| tests/lib/rules/no-v-html.js | Adds test cases for valid and invalid usage with ignorePattern option |
| docs/rules/no-v-html.md | Documents the new ignorePattern option with configuration examples |
| docs/rules/no-v-text.md | Adds related rules section for cross-referencing |
| docs/rules/no-v-text-v-html-on-component.md | Adds related rules section for cross-referencing |
| .changeset/purple-lights-invite.md | Documents the feature addition for changelog |
Co-authored-by: Copilot <[email protected]>
This allows configuring the rule such that certain variables are allowed in
v-html=. For instance, we would like to allowlist variables named “*Html” (as in the test), where the name already marks them as containing safe HTML that’s expected to be used withv-html=.I tried to follow existing code style in here, but still, this is my first time contributing to any eslint plugin (I think), so let me know if anything needs to be changed or improved :) the option name mimics e.g.
no-unused-varsbut could of course be changed. (Also, I’m not completely sure if it’s correct that the option value seems to require slashes around it in order to not be interpreted as a literal string.)