rome.requireConfiguration should be true by default?

[diraneyya]

Dear lovelies in the Rome team!

First of all I would like to really congratulate you for reaching version 12! Simple features like formatting JSON made it possible for me to finally recommend this wonderful tool in my full-stack bootcamp student projects (yes! I am a full-stack development instructor).

One thing that stood out to me (beside the inability to format JSON with comments, with an easy fix for now using file association setting in Vscode) is the default value for the rome.requireConfiguration setting.

I think it is wise at this stage to assume that most projects would be using other linters, and/or in many cases, might not need linting at all (such as in the case of built/transpiled files often in a folder named dist).

This default value is particularly unhandy when we recommend the rome vscode extension to be installed upon opening the workspace (using the extensions.json file in the .vscode folder in the workspace) since this might later make the user regret following our recommendation (when they see all those rome linting errors in other projects), especially if they are a beginner.

Hence my recommendation would be to only activate the rome plugin in projects where there is a configuration file, by default.

[ematipico]

Hey @diraneyya !

Thank you very much for your feedback! That's a great one!

You made really good points and I can relate to them.

There's few points that I'd like to highlight:

• Rome intention is to be a full working language server, which will provide more features in the future;
• I completely agree that new users might be confused and overwhelmed from seeing red diagnostics for valid code (it's the linter, damn!)

I think Rome shouldn't distance itself too much from its original goal (being a language server).

Here's what a propose: by default, if no configuration is present, the extension should show only parsing errors. What do you think? That's what the existing typescript language server does in VSCode.

[strager]

the extension should show only parsing errors

Would that include errors like the following:

const x = 3;
x = 4;  // error

[ematipico]

As for today, no.

We have a rule to catch that, but that rule it's a lint category.

Although, our analyzer infrastructure allows us to have rules for parsing/runtime mistakes that are not caught by the parser (this is a design decision). These rules can't be turned off. So potentially such rules can be included in that category.

[Conaclos]

Here's what a propose: by default, if no configuration is present, the extension should show only parsing errors. What do you think? That's what the existing typescript language server does in VSCode.

Looks fine to me :)