Ignoring lint rules in templates

[maxmilton]

Now that v2.0.0 has template linting is on by default, I'm getting a bunch of false negatives I'd like to either ignore or customise specifically for templates.

The main 2 I'm seeing (based on my rule set) is:

1. no-unused-expressions - We kind of actually want the opposite, templates should be an expression.
2. @typescript-eslint/indent (same as indent) - Triggers inside an {#each} loop.

Configs:

• https://github.com/WeAreGenki/minna-ui/blob/dev/utils/eslint-config/index.js
• https://github.com/WeAreGenki/minna-ui/blob/dev/utils/eslint-config/svelte.js

[Conduitry]

Having this plugin explicitly disable the no-unused-expressions rule in template expressions makes sense.

I'm not sure what to do about the @typescript/ rule. I'd really like to be able to draw a line about not having any special treatment for rules from any plugin (because where would the feature requests for this stop?). For this particular case, it's probably safe to use your *.svelte override to completely disable @typescript-eslint/indent in Svelte components.

Adding back an option to disable template linting entirely would probably make things smoother but it doesn't feel like the best move. I'm also worried about adding a general 'do you want to disable this message' callback in the settings, that's passed a message object from ESLint (and maybe also whether this corresponds to the template or a script) and returns a boolean. I guess overall I'd really like to push people toward configuring ESLint how they need it, rather than configuring this plugin how they need it. @typescript-eslint/indent is an example of this - there's already an official mechanism provided by ESLint for disabling this on specific files.

[Conduitry]

no-unused-expressions is now getting ignored in expressions in the template.

[maxmilton]

I agree with you about limiting fixes to built-in ESLint rules only. Easier to maintain and keeps the scope of integration testing tight.

Yeah, adding an option to disable template linting feels like a step in the wrong direction. Svelte doesn't have first-class TypeScript support yet so @typescript-eslint/indent could be replaced with regular indent for now. Even still, adding overrides for *.svelte when really we just want to target svelte templates isn't really desirable either.

The eslint-plugin-jsdoc has a similar problem and have a solution; They have a settings.jsdoc.matchingFileName setting which allows the user to change the file name passed to ESLint for matching code blocks. This then allows setting up overrides for those specific code blocks. Using the overrides mechanism allows for full config flexibility.

Not sure how viable it would be for this plugin but I can imagine setting svelte template expressions to pass a component.svelte-template file name and adding a new set of overrides.

---

For anyone running into the same original issue, you don't need to disable @typescript-eslint/indent completely, just ignore the Identifier node like so:

'@typescript-eslint/indent': ['error', 2, {
    ignoredNodes: ['Identifier'], // Svelte template expressions
  }
]

You could probably use a more specific AST pattern but this is better than nothing.

[Conduitry]

Processors in ESLint 6 got a bit of a overhaul, including a new feature called named code blocks, which seem like now the correct way to expose the ability to have different configurations for different sections of a Svelte component. I have a pending question about how these work, but in the meantime I have an implementation that uses these in my fork of this plugin.

[Conduitry]

This is implemented in 2.7.0 via named code blocks.

[Conduitry]

Adding named code blocks was actually a breaking change 😬 I've released 2.7.1 where they're disabled by default, but they can be enabled with svelte3/named-blocks.

[maxmilton]

It works. We can now create presise overrides 🎉

So useful, thank you!