feat(rome_lsp): read configuration file

[ematipico]

Summary

Closes #2861

This PR adds a feature to read the configuration rome.json file from the LSP. In order to do so, the Session has been extended with two new properties:

• file_system, the trait that we use to read files
• configuration, where we save the configuration read from the file

There's an intentional limitation here, which is if the a configuration file is found and it doesn't throw any errors, the workspace settings will use all the settings coming from the configuration.

This means that if we both have a configuration file with lineWidth set to 120, and then we have also a custom line width in the VSCode extension set to 160, the LSP will use the one inside the configuration.

Another intentional limitation is the fact that if we change the rome.json, the LSP won't pick the new change. In order to watch the change, we would need to enable the extension also for JSON language, but doing so would also enable the formatting for JSON files. Trying to format a JSON file, now, would emit a modal error inside VSCode. Not sure if that's what we want, but for now I left it out of scope.

Test Plan

I manually created rome.json config file and opened a project.

{
  "root": true,
  "formatter": {
    "lineWidth": 50
  }
}

Here's the logging:

├─343ms TRACE The LSP will now use the following configuration: 
│  WorkspaceSettings { format: FormatSettings { enabled: true, format_with_errors: false, indent_style: Some(Tab), line_width: Some(LineWidth(50)) }, linter: LinterSettings { enabled: true }, languages: LanguagesSettings { javascript: LanguageSettings { format: JsFormatSettings { indent_style: None, line_width: None, quote_style: Some(Double) } } } }

And when formatting a file, here's a piece of snippet:

const { getStdin } = require(
	"../common/third-party.js",
);

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Pages

Latest commit:	4a1cdf9
Status:	🚫  Build failed.

View logs

[github-actions]

Playground for commit 32e8c87

[leops]

Maybe we should consider deprecating loading the configuration from the editor settings. Would it be possible to emit a warning diagnostic in the vscode settings file if we detect a configuration section there ?

[ematipico]

Maybe we should consider deprecating loading the configuration from the editor settings. Would it be possible to emit a warning diagnostic in the vscode settings file if we detect a configuration section there ?

VSCode marks the removed settings with warning (yellow) underline.

Those settings are marked as "BETA" in the VSCode interface. Maybe in the next release if the configuration file land and it's stable, we can just remove them directly. They were in BETA anyway. In the changelog we can add a paragraph as migration strategy.