| I don't know whether the approach we used would work for you, but it sounds simpler to me.
I wouldn't be surprised if your architecture was much simpler. Though the use case that I'm unsure if your solution solves (which is my primary objective) is allowing any author to publish a single LintError subclass or create one within a project directory, and allow it to be bootstrapped to the same, single plugin/server instance as the rest of the lints (declared by simply naming the lint in analysis_options). The issue with architecting this via multiple plugins is of course that resources cannot be shared, and so for the average sized project, most devs would be limited to ~ 1 or 2 plugins. The solution I'm attempting to build would allow a melting pot of different global and/or project-specific rules to exist within 1 plugin with (theoretical) 1x resources, which would be more open-ecosystem like. Am I correct in assuming your solution would not allow for various non-Linter lints to work within the same resources?
I won't trivialize the complexities of this solution, incl:
- preventing/reporting poor-performing lints which affect the entire plugin
- standardizing packages that subclass LintError
- conflicting error code definitions (e.g. "avoid_string_literal" from l10n package vs "avoid_string_literal" from some other translations package)
However, for each complexity, I've been able to implement working solutions, or have plans to do so, and the upside is (IMO) Dart-tier devX and greatly reduced barrier to entry for developers to further customize their own IDE experience, which I believe has a lot of very interesting applications.
| If it works at all it's an accident, not an intentional feature.
| I was able to have something working relatively well. But I don't remember exactly what I did
| most probably just removing the whole directory. And I think I was restarting the whole analysis server
I'm glad to know I'm not going crazy by also not being able to pin point the solution :)
Deleting the PluginManager folder, restarting the server, and changing overrides... some combination of those seem to sporadically work for me as well. I'm about 60% sure this is only a development problem, as things seem to work fine when pulling all packages from pub instead of from-path overrides. If thats not the case then we can cross that bridge after the proposal is out there (~ 1 week out from publishing something).