oxlint-plugin-vue-sfc

oxlint-plugin-vue-sfc

Vue SFC template rules for oxlint, as a JS plugin.

oxlint cannot read Vue templates natively (oxc#15761), so projects keep ESLint around for eslint-plugin-vue. These 24 rules self-parse the SFC with @vue/compiler-sfc and walk the real template AST, so the checks run under oxlint instead.

Ports of eslint-plugin-vue rules that oxlint has no native equivalent for. Validated against a production Nuxt monorepo — 1581 SFCs, all template-first — where they replaced the corresponding vue/* ESLint rules outright.

Install

npm i -D oxlint-plugin-vue-sfc

Usage

Extend a preset from your .oxlintrc.json:

{
    "extends": ["./node_modules/oxlint-plugin-vue-sfc/configs/recommended.json"]
}

Two presets:

Or wire it up by hand:

{
    "jsPlugins": ["./node_modules/oxlint-plugin-vue-sfc/index.mjs"],
    "rules": {
        "vue-sfc/require-v-for-key": "error",
        "vue-sfc/no-raw-text": "off"
    }
}

The plugin namespace is vue-sfc, not vue — oxlint reserves vue for its native plugin and rejects a JS plugin that claims it.

Rules

no-raw-text defaults to off: it is an i18n rule (a replacement for @intlify/vue-i18n/no-raw-text) and only makes sense in a translated app. It takes { ignoreTags, ignorePattern }.

Known limitation: diagnostic positions

Template diagnostics currently render on the <script> block, with the true template position prepended to the message:

Comp.vue:13:1  error  vue-sfc(require-v-for-key): [template 3:9] <li> uses v-for without a :key...

oxlint gives JS-plugin rules a script-relative view of an SFC, so a template position — which in a template-first file is a negative offset — cannot be expressed. The workaround clamps the range and puts the real location in the message text.

oxc#26001 fixes this upstream with an actualRange on the diagnostic, and would give every rule here correct positions with no rule changes. Until it lands, editor jump-to-error goes to the script block.

Reduced-scope ports

Six rules deliberately implement less than their upstream counterpart. Each says so in its own file header:

• no-dupe-v-else-if — exact duplicate conditions only, not subsumption
• this-in-template, no-mutating-props — lexical template scan
• require-explicit-emits — silent on an unresolvable named type reference
• no-unused-vars, no-template-shadow — positioned scan, not a full destructuring-pattern parse
• no-unused-components — upstream only inspects Options API components: {}, so it is inert in a <script setup> codebase; ported so the check does not vanish if that changes

They gate new violations rather than opening a migration: all 24 report zero diagnostics across the 1581-SFC corpus they were built against.

Tests

npm test    # node:test, 324 specs across 24 rules

License

MIT