6896a21216
* Combine DartFixContext and DartFixContextImpl into one class; separation seems unnecessary. * Change constructor (which was on DartFixContextImpl) to use all named parameters. * Change `resolveResult` field to `resolvedResult`, since the type is called `ResolvedUnitResult`. * Start doc comments with third person verbs [1]. [1]: https://dart.dev/effective-dart/documentation#prefer-starting-function-or-method-comments-with-third-person-verbs Work towards https://github.com/dart-lang/sdk/issues/53402 Change-Id: Idb3c6776f899d5bc9b634c1d9c4b998de2603d04 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358382 Reviewed-by: Konstantin Shcheglov <scheglov@google.com> Reviewed-by: Brian Wilkerson <brianwilkerson@google.com> Commit-Queue: Samuel Rawlins <srawlins@google.com> |
||
---|---|---|
.. | ||
lib/edit/fix | ||
analysis_options.yaml | ||
CONTRIBUTING.md | ||
LICENSE | ||
OWNERS | ||
pubspec.yaml | ||
README.md |
server_plugin package
This package is being developed for the second incarnation of Dart Analyzer plugins. It is in an intermediate state, and a few things must be kept in mind during this phase of development:
- This package is not to be published on pub. Yet. We may decide to go
forward with this package as a full replacement of the
analyzer_plugin
package, in which case we would ultimately publish it. But we may choose a different plan. Until we finalize, this package is not to be published. - In order to support the above point, no pub-publishable code can depend on
this package. At no point can we introduce a dependency from a package
like
analyzer
oranalyzer_plugin
to this package. If we did so, then at the next time we published that package to pub, we would need to publish this package to pub. No. In short, I think what this means is that only theanalsis_server
package can depend on this package (until we decide the final path to publishing the next Dart Analyzer plugins story.
Migration of code between packages
As part of the design of the new Dart Analyzer plugins, much code will shift around, in a few directions.
-
analysis_server
package toserver_plugin
package: The API of the new Dart Analyzer plugins focuses around two primary concepts: lint rules and quick fixes. Quick assists may be chosen as a third important concept. Lint rule code has typically lived in theanalyzer
package, and does not need to move. (It's presense in theanalyzer
package could be deprecated in favor of this package, but it is not important for the implementation.)Quick fixes, however, have only existed in concept, and interface, and API, in the
analysis_server
package. That code needs to move to this package in order to be used in a Dart Analyzer plugin.A move from the
analysis_server
package to this package is not a breaking change. -
analyzer_plugin
package toserver_plugin
package: Care is being taken to decide where Dart Analyzer plugin code will live and how it will be published. It is not decided yet what the ultimate package API will be. Some code from analyzer_plugin may move to this package.A move from the
analyzer_plugin
package is a breaking change. Extreme care must be taken. -
analyzer_plugin
package toanalysis_server
package: There will be many components of the analysis server that currently live inanalyzer_plugin
, because they were necessary for the first version of Dart Analyzer plugins), but are not part of the new Dart Analyzer plugins. These components can be moved safely back into theanalysis_server
package.In terms of priority, it is not crucial for such code to be moved out of the
analyzer_plugin
package. It can live there indefinitely, and theanalysis_server
package can continue to depend on code from theanalyzer_plugin
package, as shipped in the SDK.A move from the
analyzer_plugin
package is a breaking change. Extreme care must be taken.