☂️ Dependencies analysis

[ematipico]

Description

Create a new crate to analyze the dependencies of a JavaScript project.

Since we don't support CSS, the crate will initially work only with JavaScript files.

I don't have a clear idea yet of how to break down the work; any input on this umbrella will be of great help.

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]

Can you convert this to a discussion for structured comments?

---

A few points:

analyze the dependencies of a JavaScript project

Probably need to scope this down:

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

build the dependency graph

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 https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-single-module-script because I couldn't figure out all the cyclic dependencies.

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

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.