[Announcement] Introducing Linting for Tailwind CSS IntelliSense

[bradlc]

Today we’re releasing a new version of the Tailwind CSS IntelliSense extension for Visual Studio Code that adds Tailwind-specific linting to both your CSS and your markup.

Detecting errors in your CSS

Tailwind already detects CSS errors, for example when you mistype a screen name in the @screen directive. The linting feature for Tailwind CSS IntelliSense surfaces these errors and displays them in context, directly inside your editor. The linter will validate your @tailwind, @screen, @variants and @apply directives, as well as any theme function calls:

Catching conflicts in your HTML

There is one more lint rule which analyses class lists in your template files and highlights any instances where utilities seem to be in conflict. For example you probably didn’t intend to have mt-4 and mt-6 in the same class list!

Quick fixes included

To make it as easy as possible to fix any issues, all of the lint rules have their own "quick fixes" which can be triggered directly within Visual Studio Code. If you accidentally typed @screen small instead of @screen sm, the editor can automatically replace small with sm for you!

As well as simple text replacements there’s also some more interesting quick fixes for the more complex lint rules. Take a look at how the extension can automatically refactor an invalid @apply directive: https://twitter.com/bradlc/status/1273271040886611976

Configuration

We think you’ll love the new lint feature, but if you don’t, or you just want to tweak some behavior, we’ve got you covered. You can decide how each rule violation is treated: is it an error, or just a warning, or do you want to ignore the rule altogether? If you really want to you can disable linting entirely using the new tailwindCSS.validate setting.

Check out the extension readme for more details about configuring the lint rules to suit your workflow.

Conclusion

Linting is available now in v0.4.0 of Tailwind CSS IntelliSense! If you already have the extension you may need to reload Visual Studio Code to get the update, and if you don’t you can install it via the extension marketplace.

This is the very first iteration of this feature, and we’d love to hear your feedback! Do you have an idea for a new lint rule? Let us know!

[OwenVey]

I'm getting a warning when using a text color alongside a group-hover text color, is this expected?

[bradlc]

Definitely a bug! 🐛 Thanks, I have create an issue

[rik]

The class conflicts are a great idea! Is there any plan to integrate with some kind of CLI linter (I'm thinking about stylelint for CSS, no idea what exists for HTML-ish files)? That would be super nice to keep a project clean, regardless of developers' editor of choice.

[TheDoctor0]

Are there any plans to port this extension to a JetBrains IDE plugin?

[adampatterson]

I was thinking the same thing :)

[DCzajkowski]

I really like the way this is going and I have to say you have done a great job! But I have my thoughts on the implementation.

Usually, I don't use intellisense extensions that are not in ESLint (or project configuration) because when I work on someone's code who doesn't use those extensions, I create a lot of changes unrelated to my feature.

Another thing is, that if this was an ESLint plugin, it wouldn't be editor-specific — giving support to everyone working on the project (be it a Vim or Sublime Text users).

I think having an extension that gives you a popup with suggestions (typeahead) makes a lot of sense to be editor-specific. But an extension that provides additional linting should be exported into an external tool — be it Tailwind CLI or ESLint plugin (as long as it can be enforced in CI) and configured in project's git-commitable files.

Editor plugin pros

• strict integration with VSCode
• easy to setup

Tailwind CLI or ESLint plugin's pros

• editor agnostic (automatic editor integration via already-existing ESLint plugins)
• easier to maintain (project is a common ESLint plugin, no proprietary solutions)
• can be enforced in CI
• its configuration is commited in the project — better shareability

Please let me know what you think :)

EDIT: I have learned integrating this into ESLint could be impossible due to no HTML parsing capabilities. I guess Tailwind CLI would be a great place to have this. I guess the extension would simply call the CLI not to duplicate code.

[skoshy]

Agreed, I personally use VS Code, but I'd love it if these rules were implemented in ESLint so other team members can use it. Having the rules being able to be forced in CI as well is a great bonus.

[skeeith]

Was here looking for Sublime Text linting support

[joeynimu]

I totally agree with @DCzajkowski here. The editor plugin is good as it is, but it'd be nice to have the tool extracted away from an editor plugin when working with a team. The plugin is still helpful, but we can also enforce this at the CI level. Are there any plans for this?

[yabdab]

The linting works on .html files, but not .php files. How to fix that?

Also, any thoughts of making an extension for Panic's new Nova app ( Coda successor ) ?

TIA

[johnpangalos]

Hey, is there any way to run the linter by itself? It would be nice to be able to run it in our pipeline.

[dolanmiu]

Hey, is there any way to run the linter by itself? It would be nice to be able to run it in our pipeline.

Yes, this is now possible. Check out the eslint package:

https://www.npmjs.com/package/eslint-plugin-tailwindcss