Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 29 additions & 0 deletions .eslintrc.js
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,9 @@ module.exports = {
'plugin:vue/vue3-recommended',
'@vue/airbnb'
],
plugins: [
'@intlify/eslint-plugin-vue-i18n',
],
globals: {
$: 'readonly',
alert: 'readonly',
Expand All @@ -15,6 +18,29 @@ module.exports = {
defineModel: 'readonly'
},
rules: {
'@intlify/vue-i18n/no-unused-keys': [ 'error', {
src: 'src/',
callExpression: '^(\\$t|t|\\$tc|tc|\\$tcn|tcn|\\$tn|tn)$',
Copy link
Member

Choose a reason for hiding this comment

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

Once #1026 is complete, there won't be a $tc() or tc() anymore. At that time, we'll probably rename $tcn() to $tn().

Currently, there is $tcn(), and there is tn(); there's no $tn() or tcn(). The asymmetry is because we've had $tcn() for a long time, while tn() was added around the time that we moved to Vue 3 and started using the Composition API. In the context of Vue I18n within the Composition API, tc() is deprecated, because t() now does what $t() and $tc() both used to do.

Copy link
Member

Choose a reason for hiding this comment

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

Re: being blocked by intlify/eslint-plugin-vue-i18n#643, I have two thoughts:

  1. Maybe we just ignore $tcn() and tn() for now. They're not the most common way to access i18n messages.
  2. What if in CI, we modified code files, e.g., replacing all strings containing /\btn\(/ with t(? Would the Vue I18n check work then?

ignores: [
// /^[\w-]+\./ should match all locale keys, e.g. "en", "zh-Hant" etc.
/^[\w-]+\.audit\.action\./,
/^[\w-]+\.audit\.category\./,
/^[\w-]+\.back\.back$/,
/^[\w-]+\.back\.title$/,
/^[\w-]+\.component\.WebFormRenderer\./, // dynamic modals
/^[\w-]+\.conflict\./,
/^[\w-]+\.fields\./,
/^[\w-]+\.oidc.error\./,
/^[\w-]+\.outdatedVersionHtml\./, // check that file's comments
/^[\w-]+\.reviewState\./,
/^[\w-]+\.steps\[0\]\.introduction\[1\]\[0\]$/,
/^[\w-]+\.tab\./,
/^[\w-]+\.title\.submissionBacklog\./,
/^[\w-]+\.title\.updateReviewState\./,
/^[\w-]+\.type\./,
Comment on lines +26 to +40
Copy link
Member

Choose a reason for hiding this comment

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

You wrote in the PR description:

Currently the ignore rules are very general, and won't detect e.g. unused back keys mentioned in getodk/central#1350. This might be improved by something like intlify/eslint-plugin-vue-i18n#668.

The list of exceptions here is indeed longer than I'd expect. We probably wouldn't have to add to it super often though. I am a little concerned about false negatives though. It seems like the check will ignore a lot of messages. I guess checking most messages is much better than checking no messages though.

It makes sense to me that messages that are accessed via dynamic/constructed keys need to be in this list, e.g., /^[\w-]+\.audit\.action\./. I don't understand some of the other cases though, e.g., /^[\w-]+\.fields\./ or /Modal\.(body|title)$/. If we decide to run with this PR, maybe I can take a closer look at the list and try to figure out if there are ways to ignore fewer messages.

/Modal\.(body|title)$/,
].map(re => re.toString()),
}],
'arrow-parens': 'off',
'class-methods-use-this': 'off',
'comma-dangle': ['error', 'only-multiline'],
Expand Down Expand Up @@ -51,6 +77,7 @@ module.exports = {
asyncArrow: 'always'
}],
'spaced-comment': 'off',
'vue/attribute-hyphenation': 'off',
Copy link
Member

Choose a reason for hiding this comment

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

You wrote in the PR description:

This PR also seems to introduce a bunch of other new vue eslint rules, which are then disabled in this PR. That doesn't seem ideal; maybe they need to be evaluated and enabled separately.

I wonder if we need to update our version of eslint-plugin-vue. That's probably something I can do as part of #974.

Just based on their names, vue/require-prop-types and vue/no-constant-condition sound potentially useful.

One approach we could take is disable these rules for now, but file a follow-up issue to consider reenabling them.

'vue/attributes-order': ['error', {
order: [
'LIST_RENDERING',
Expand All @@ -76,6 +103,7 @@ module.exports = {
selfClosingTag: 'never'
}],
'vue/html-indent': 'off',
'vue/require-prop-types': 'off',
'vue/html-self-closing': ['error', {
html: {
void: 'never',
Expand All @@ -87,6 +115,7 @@ module.exports = {
}],
'vue/max-attributes-per-line': 'off',
'vue/multi-word-component-names': 'off',
'vue/no-constant-condition': 'off',
'vue/no-setup-props-destructure': 'off',
'vue/no-template-target-blank': 'off',
'vue/object-curly-newline': 'off',
Expand Down
Loading
Loading