package:sidecar - Single-isolate, multi-package lint architecture

[Patt O'Brien]

Hi everyone,

I'd like to introduce an analyzer_plugin package I've been working on for a while: sidecar. One of the main goals of the package is to enable lint/quick-assist/etc rules, defined within multiple packages, to run on a single, shared isolate. For more info on the architecture, you can check out this architecture doc.

If you're curious to see some packages built on top of sidecar, see: design_system_lints or dart_lints (a port of official linter rules, for PoC / benchmark reasons). 

I'm hoping that this package can serve as a PoC of a different architecture than analyzer_plugin, one which reduces performance issues and which offers a simpler API for rule developers. The github docs also include some working designs of how we can handle various complexities, such as versioning, rule maintenance, reflecting types declared in ecosystem packages (e.g. flutter, riverpod, bloc, etc), and a couple more important topics.

I'd appreciate any feedback, ideas, or critiques, to see if the architecture truly works and can hold up to Dart's quality standards.

Patt

[Max Tamburini]

Hello Patt,

I remember you on the dart_custom_lint's issues on Github, I'm glad to see you active on this topic. :)

I haven't had the time to check your work so far (I'll do soon), but what are the main difference between sidecar and dart_custom_lint?

Max

[Patt O'Brien]

Hey Max -

Thanks a lot for the support! I'll start with a few technical differences in current implementations of each package:

- Sidecar is built to run all Rule packages on a single isolate, whereas DCL runs each package on a separate isolate (although Remi plans on doing the same in DCL eventually); this results in significant less memory usage when using multiple rule packages

- Sidecar Rule definitions are very closely formatted to the Dart official lints, especially when using AstVisitors as the base for Rules (early benchmarks showed this was the most performant, scalable architecture); with DCL, all rules start with a ResolvedUnitResult, whereas Sidecar Rules are subclasses of AstVisitors; so Sidecar rules only need to operate on specific AstNodes (e.g. if my rule needs to only analyze strings, then I use ```visitStringLiteral``` method only)... on the other hand, DCL must essentially traverse the whole AST for every lint definition. for more info on potential pros/cons, see this well written issue

- configuration features (via sidecar.yaml): includes/excludes globs (on project-specific, package-specific and/or rule-specific level), override default lint severity , url links to lint documentation in IDE hover window, and many more features planned (see features)

On a forward-looking level, I'm looking to go outside of the scope of a simple analyzer_plugin in terms of improving the entire usage DevX; for example, I'm prototyping ways to use reflection as a means to simplify the way rules can be written. (checkout the readme here for some rough ideas on utility improvements). I'm focused on making rules as simple to create and maintain as possible, so that you can easily distribute your own rule packages or simply set them up a couple lints for a short-term project.

All of this said, Sidecar was initially influenced by DCL and other similar projects, and I'm specifically creating a lot of architecture documentation in hopes that projects like DCL can take what they want from them. Ultimately, I'm very passionate about spearheading this effort to build upon the already incredible Dart tooling, and I'm determined to make Sidecar a powerful multi-purpose tool to make the community more efficient at developing apps.

Though I'm aware of some bugs here and there, the current version of sidecar works well from my preliminary tests; if you decide to try Sidecar out, I'd sincerely appreciate any feedback you have, positive or negative! :)

Patt

[Max Tamburini]

Hello Patt,

It sounds good to me. I really like the idea of using this tool for improving the DevX, I looked at DCL precisely because of this.

- You can create a set of rules to help developers in their work whenever are using the 'vanilla' Dart or packages.

- Every package author could create their set of rules to establish that its package is used in the right way, creating a standard convention.

- You can also create a set of rules for your team to ensure that they follow your convention (like the eslint config of airbnb).

These are my first thoughts that come to mind.

By the way, I am interested in the Quick Assists usage: I can see in the issue opened on your repo that it could be a problem related to the analyzer_plugin, due to the missing signals of edit.getAssists and edit.getFixes.

Have you already talked to the Dart Team about this?

Max

[Patt O'Brien]

Hey Max -

You hit on some of the biggest use cases that inspired me to commit 100% to this project - the potential such a tool has seems huge IMO.

As far as the Quick Fix issue you pointed out, I was able to find a solution based on another discussion I had here about the analyzer_plugin spec; I added that solution to the issue for your reference, but will keep the issue open as a reminder to explain this in the docs. I also opened up an issue against Dart for the actual bug, which was that lints should not appear for dependencies unless explicitly enabled in analysis_options.yaml.

As for Quick Assists, they're planned for right after I wrap up one last architecture decision, but I did test assist functionality a couple months ago and know that the analyzer_plugin has the feature working 100%. The feature just needs to be re-enabled in sidecar, which I hope to get around to within the next two weeks or so. If there's an assist use case you're dying to try out, I can shift some priorities around to ship that feature sooner - just lmk.

Anyways, I've been diligently testing sidecar and adapting the APIs to make them as intuitive as possible, but a fresh perspective would be super valuable to guiding bug/feature/docs priorities. If/when you try to create your own lint rules, I would really appreciate any feedback you have, like whether the usage guides are sufficient or not. I also plan to put out some videos showcasing full functionality some time early Jan, and expect that will answer a lot of questions.

Thanks for the interest and feedback, its seriously appreciated!

Patt

[Max Tamburini]

Hello Patt,

Sorry for the late reply.

It's not urgent because I am pretty busy right now, but I'd like to give it a try and develop a lint rules soon or after.

I'll let you know when I'll start to working on it.

Good job and keep it up! :)

Max

[Patt O'Brien]

Hey Max -

Sorry for the delay, I'm just now seeing your past message after getting some much needed time away from the desk :)

I'm stoked to hear you're going to give sidecar a shot! Just today I pushed a dev.19 version with some performance enhancements and support for Windows (now works on all platforms).

I want to make sure I'm incorporating community feedback as early on as possible (before more publicly launching a beta), and since you seem to fit the bill for wanting to try it out + understanding the potential of the project, I deployed a documentation site to help get you started (including 1 solid hello world guide, with 2 others to follow by end of the week). You can check it out at https://sidecaranalyzer.dev - let me know what you think!

I also created a discord server for you or anyone else to ask any questions (questions on sidecar, analyzer, or specific use cases for your application), and would be more than happy to help you navigate the APIs there. The link is in that same doc site.

Looking forward to hopefully chatting with you there!