Dependencies analysis

[ematipico]

Description

Some initial thoughts:

• we need to find a way to pass the virtual file system to the Workspace. Project analysis requires reading files from disk. Currently, the dyn FileSystem is created and passed to Rome as an argument, but eventually, the file is processed by the Workspace without the need for the file system. We have an internal cache where we save the content of a document and its AST. There are few options we can evaluate:
  • build the dependency graph before processing the files - walking the file system, and pass the graph to the tools that need it. We should be able to apply this strategy to the LSP too.
  • pass the FileSystem to the workspace. This is the best solution, although we need to find a way to make it thread-safe, because the Workspace is safe across thread boundaries and can't panic.
• do not support aliases for now, we would need tsconfig.json support, which we lack - we need support comments in JSON files, e.g. feat: 🎸 allow comments in json file #4382
• The dependency graph needs to be used inside the linter somehow. We have few options here, we can use it inside the existing rome_js_analyze or we could think about having a new crate.

[Boshen]

analyze the dependencies of a JavaScript project

[Boshen]

Probably need to scope this down:

A TypeScript project?
A node.js project?
A CJS or ESM project?
... and the list goes on

[Boshen]

build the dependency graph

[Boshen]

I did this for the internal version of Oxc. There are a few prerequisites:

Path Resolution - need enhanced-resolve or a Rust version
Module Record - in js we have es-module-lexer, in Oxc I did my own implementation
A (nice to have) abstraction for Host, Realm, Environment and ModuleRecord from the html spec - this leads you to a nicer implementation of graph resolution. I followed the algorithm from the html spec html.spec.whatwg.org/multipage/webappapis.html#fetch-a-single-module-script because I couldn't figure out all the cyclic dependencies.

[Boshen]

The dependency graph needs to be used inside the linter somehow.

[Boshen]

I also implemented this for my internal version. You need to be careful with your implementation, a single export * can blow up everything ... performance and memory wise.

I think an event system is needed, where you signal the linter a particular file's dependencies are all resolved, and is ready for lint.

The linter can take in the whole semantic facade and assume all dependencies are resolved.

[strager]

Some (most?) lint passes/rules don't need dependency information. I think Rome shouldn't delay those rules while dependency analysis is running (unless dependency analysis is fast, but it sounds like it won't be fast).

[ematipico]

Some (most?) lint passes/rules don't need dependency information. I think Rome shouldn't delay those rules while dependency analysis is running (unless dependency analysis is fast, but it sounds like it won't be fast).

Fortunately our analyzer infrastructure is meant to not delay rules that don't require additional information (semantic model for example)