Built-in linter system

[timotheeguerin]

Bring this back on the table. We are currently using @typespec/linter a library to make linter rules that plug in the onValidate step of the typescript compilation.

The problem with this approach:

• getting issue when libraries get loaded twice(e.g. different version loaded in emitter jscode and typespec import)
• not very clean to enable rules provided by another library
  • was actually disabled in Remove global state from linter library #1794 as it was causing global state conflict

Idea with a built-in linter system is that the compiler would be aware of the various linting rules and allow better customization from other libraries and spec author.

Ideas

This is just some idea but could have something like this in a spec

#enable no-inline-models warn
#disable no-unions

this could even be the way libraries decide which rules they enable themself.

Other related issues

• Mechanism for emitter or library to hook into dependent library's diagnostics #1743 Ability for another library to elevate a warn as an error

Proposal https://gist.github.com/timotheeguerin/9d665c82f89d3a07a406a8928fb1e2bd

[nguerrera]

I like this idea a lot.

[timotheeguerin]

Items to consider for built-in system:

• library MUST declare the list of linting rules ahead of times(maybe just exported via the $lib)
• ideally linting rule emit diagnostic with the name code as the linting rule name
• ability for a library to decide which rules are enabled by default and their severity
• ability for spec writter or anther library to enable, disable or change severity of rule
• optional: Ability for a library to define a ruleset that can allow quick enablement of different ruleset
  • e.g. #enable @typesopec/bestpractices:recommended or #enable @typesopec/bestpractices:all
• Another thing is scope of linting rules. Should there be a way to say that the rules only apply to certain namespace(or exclude form certain namespace). But maybe this is out of scope of this and more about suppression logic.

[timotheeguerin]

Another thing we might want to consider is the scope of a linter rule. Lets say you have 2 services defined in the same spec. Each service is using a different library with different set of rules. We probably want to make sure only the relevant linter rules are enabled per service. This would mean having some kind of scope for where the rules can run.

[timotheeguerin]

Proposal https://gist.github.com/timotheeguerin/9d665c82f89d3a07a406a8928fb1e2bd

[timotheeguerin]

implementation here #1996