Parser Rework: NPM Package Support, import/export tracing, Internal Structure Refactor, Playground and more

[marcoroth]

This pull request is a big revamp of the existing parser and also adds a lot of new features. Here are the highlights:

NPM Package Support

We now fully support Stimulus controllers imported from NPM packages installed on disk. We can trace the import declaration to the resolved source file within the NPM package. If the import is importing a class declaration, we can fully resolve the import to the class declaration in the NPM package.

Sadly the parser doesn't yet resolve controllers imported from import-mapped NPM packages.

Stimulus Parser Playground

The pull requests features a fully interactive web-based playground to interact and inspect the parse results. The playground allows users to encode the input into a sharable URL that can come in heady for bug and issue reports.

New Internal Structure and classes to represent objects

We already had:

• Project
• Parser
• ControllerDefinition
• MethodDefinition
• ValueDefinition
• ClassDefinition
• TargetDefinition

Newly added:

• SourceFile - A representation of a (parsed) JavaScript/TypeScript source file.
• ImportDeclaration - A representation of an import declaration within a SourceFile. If a single import statement imports two constants it will be represented with two ImportDeclaration objects. We decide between default, named and namespace imports.
• ExportDeclaration - A representation of an export declaration within a SourceFile. If a single export statement exports two constants it will be represented with two ExportDeclaration objects. We decide between default, named and namespace exports.
• ClassDeclaration - A representation of any class declaration within a SourceFile. If class declaration defines a Stimulus controller it will have the controllerDefinition populated.
• NodeModule - The node module represents a detected NPM package. It holds a SourceFile for each file it contains.
• ApplicationFile - The file where the Stimulus application is defined/started in and exported from.
• ControllersIndexFile - Responsible for detecting the registered controllers on the application.
• RegisteredController - A ControllerDefinition /identifier pair register which controllers where registered on the application with which identifier.

Analysis of registered controllers on the Stimulus application

The Project now exposes controllerDefinitions and registeredControllers, where controllerDefinitions contain any of the controller definitions the parser found in the project and registeredControllers are the controllers the were actually detected to be registered on the Stimulus Application with an identifier.

The controllerDefinitions have a guessIdentifier property that uses a best effort strategy to come up with the most likely identifier somewhere would register this controllers as, this also includes controllers found in the installed NPM packages.

The registeredControllers have an identifier property, for which we are certain the this controller was registered with this identifier, either by manually calling application.register(...) or through one of the autoload plugins we support. Currently we have support for the following mechanisms:

• register
• stimulus-loading-lazy
• stimulus-loading-eager
• esbuild-rails
• stimulus-vite-helpers
• stimulus-webpack-helpers

But we would love to implement support for other autoload mechanisms.

Test coverage

This pull requests also introduces tons of new tests to make sure we ensure we don't introduce any regressions.

Resolved Issues

Closes #29
Closes #51
Closes #52
Closes #54
Closes #61
Closes #63
Closes #64
Closes #65