Vision of a linter ecosystem

[Shinigami92]

Concept of Eco-System

Summary

This issue will be very huge and explains what I (@Shinigami92) think would be a really leading way of which direction this tool can grow.

Motivation

Nowadays there are many linters out there but only for one or few languages.
Therefore when working e.g. on a frontend project, you need to choose eslint, htmllint, stylelint and some others and you also need to setup different schemas of configurations.

Detailed Design

• Do not prefer any language, do not provide them from core
• Plugin-System
• Providers
• Core-API
• Editor-Extensions
• Rules and Rule Severities
• Documentation / Website
• Focus on linting / hinting.

Do not prefer any language, do not provide them from core

We should create a core that doesn't prefer or support any language by default.
Also javascript should be a plugin on it's own.

Plugin-System

We should think about a plugin structure so the core can load them on demand and provide lint messages for different langauges.

First idea would be to scan node_modules folder and search for packages like @linter/plugin-{lang} and linter-plugin-{lang}.
Keep in mind that there are also languages like objective-c, so there could be a plugin like @linter/plugin-objective-c 🤔

The core collects all scoped files (with glob pattern) and then emit the files to the plugins.
The plugins processes the received file and produces well defined linting information.
The core collects the results and provide these lint-information collection so a CLI or IDE/Editor extension can consume it.

Providers

This is NOT my idea! But I like the idea of provide providers for already existing linting tools. (like eslint, prettier, stylelint, htmllint, pug-lint, ...)
These provides can be like a bridge between our tool and the specific linting tool.

The provider use the underlying tool and converts the information to our well defined linting information.

Core-API

The core API should "just" emit files and receive info objects and produce consumable lint-collections.
This collection can then consumed by the CLI or any IDE/Editor extension.

The core should also handle configuration (glob-pattern (include / exclude), rulesets and so on).

Editor-Extensions

We should create extensions for big IDEs/Editors like VSCode.
Each extension can use the @linter/core under the hood and use the collection object to display messages in the related GUI.

Rules and Rule Severities

Rule structures should be well defined so they can generically consumed by the core.
Rule structure are not related to a specific language (like HTML-rules are structured that way...) -> we define the standard / structure!

Rules could be categorized into:

• fatal: broken syntax
• hinting/guiding: like warnings that help to improve code
• stylistic: info about e.g. how to format

Rules can have one of three severity levels: off, warn and error.
Idea: we could also define info 🤔 (for stylistic)

Documentation / Website to explain the concept

We should initiate a website (#8) to help customers to create plugins, rulesets, contribute to our repos and so on.

Focus on linting / hinting.

This should be a linting tool!
Formatting should be done by tools like Prettier.

We should think and plan to support auto-fixing, but this could be done in a much later planned step.

We can provide a bridge for tools like prettier, but then only to hint/guide stylistic lint messages.

Open Questions

• How to provide different rulesets for the same langauge?

• Because I'm not onboarded currently into the existing project, it would be helpful to get an explanation of what the project is currently doing / what direction was aimed.
  Maybe I can merge some other ideas (like providers) also into my concept 🙂

• Would someone working on a Golang, .Net, Rust, C++, PHP, etc. project install a javascript package for it's linting/formatting needs?

• How will the config look like, will there be different config files for each language or will there be a single linter config for all languages?

• Global vs local devDependency

Help Needed

Of course!

I never created emitters by my self, so this would be new to me.
Interessting task to tackle 🙂

Frequently Asked Questions

Currently none

Related Discussions

Currently none

[zimme]

I'll refrain from comment on your ideas and your view of where this project could go, for now, and I'll instead try and paint a clear picture of my thinking and motivation around this project and where the project currently is, as far as I can remembers as it's been quite a while since I had time and motivation to work on this project.

Background
After I took over maintaining prettier-eslint I saw other tools like prettier-stylelint and prettier-tslint and thought that they all could share a common base as they all run prettier and some other tool before/after prettier.

When I started to conceptualize this "base", linter.js is what I came up with and in my mind it was always intended to be a linter and formatter aggregator in the same way prettier-eslint is. i.e. if I have eslint, prettier, stylelint and linter installed in my project I should be able to lint and format/auto fix any .js file with both prettier and eslint and any .css file with both prettier and stylelint by using linter and it's providers. I would need configurations for each tool separately instead of trying to override or infer config options.

As mentioned in the previous section I also didn't want to bring in the complexity that lives inside prettier-eslint becuase of it trying to infer prettier config options from eslint rules and with projects like eslint-config-prettier I don't feel infering prettier config options and the complexity it brings is worth it.

Another thing that I realized that a solution like this could help with is not having to "re-implement" editor plugins for each linting/formatting tool like what's usually done today, and a single "linter.js" editor plugin could be used for multiple linters/formatters.

Current state of the project

@linter/core
This is basically working the way I imagined, however there are things that might needs fixing/changing...
The main export is the Linter class which will load providers on construction based on what providers it finds in the closest package.json dependencies. It will look for packages named linter-provider-*, @linter/provider-* or @*/linter-provider-* and relatively require those modules.
For each provider it gets the providers LinterAdapter using the factory function which might be async. Then for each supported extension of this provider it adds the LinterAdapter to a Map of linter adapters based on supported extension.
The constructor then creates a format and lint function based on the linter adapters map.
The lint and format functions lints and formats the text it gets based on the filePath it gets. If I remember my thinking here correctly the editor extensions that format/lint text that hasn't been saved to a file yet should provide a dummy file path which should contain the file extension based on what type of content is being edited.
The lint and format result output is based on eslint's result format.
@linter/provider-eslint
This is a working provider for eslint, as far as I remember. Might need changes and updates to be more performant, etc.
@linter/provider-prettier
This is a working provider for prettier, as far as I remember. Might need changes and updates to be more performant, etc.
@linter/cli
I started development of this and have some code locally on my computer that is based on ink.
I'll push this to a branch.

[Shinigami92]

I'll refrain from comment on your ideas and your view of where this project could go, for now.

OK, but please response to it, so I can see if you understand my design and like my idea 😃

---

Background: maintaining prettier-eslint, base for tools like prettier-stylelint and prettier-tslint
base-api/interface, no "re-implement" for extensions

Yes, I like this 🙌,
but doesn't the project do the same thing as just running these two commands (aside from providing a bridge and an interface for prettier and toolX for extension developers)?

yarn format && yarn lint --fix

I would like to take your idea a little further by aiming for greater language/tool coverage. So instead of calling eslint directly, I would like to call plugins, which could be a @linter/bridge-eslint or a @linter/bridge-java-compiler. In the first phase, the plugin will just translate the errors reported by eslint/toolX into our API format. In a later phase, I could imagine including the eslint/toolX feature set in a plugin called @linter/plugin-javascript itself.

I will try to summarize my idea a little bit more briefly:

• A linter that can support and process any language via plugins (such as Java or Objective-C). So just calling yarn lint (linter-cli .) will lint everything in the current directory!
• Use bridges/providers to support existing linters and transform it to our standardized API format.
• In addition, provide a standardized API that can be read by CLI and extensions
  ... and thus simplifing the work for both
  • developers (don't need to write an extension for every tool)
  • and users (don't need to remember the various extension commands)

So could the current state of the project possibly be moved to a more descriptive project / npm package name?
How about eg @linter/prettier-lint-aggregator.
Then we can realize this vision under this currently claimed repo / npm package name.

---

based on / using ink

I have never heard of ink, but it looks interesting, especially since Yarn v2 uses it and ink works very reactive. Hope this also works under Windows CMD etc.

---

I'll push this to a branch

That would definitely help me 👍