custom_lint 0.1.0

Lint rules are a powerful way to improve the maintainability of a project. Custom Lint allows package authors and developers to easily write custom lint rules.

0.1.0

• Breaking: The plugin entrypoint has moved.
  Plugins no-longer should define a /bin/custom_lint.dart file. Instead they should define a /lib/<my_package_name>.dart

• Breaking: The plugin entrypoint is modified. Plugins no-longer define a "main", but instead define a createPlugin function:

  Before:

  // /bin/custom_lint.dart
  void main(List<String> args, SendPort sendPort) {
    startPlugin(sendPort, MyPlugin());
  }
  

  After:

  // /lib/<my_package_name.dart
  MyPlugin createPlugin() => MyPlugin();
  

• Add assist support. Inside your plugins, you can now override handleGetAssists:

  import 'package:analyzer_plugin/protocol/protocol_generated.dart'
    as analyzer_plugin;
  
  class MyPlugin extends PluginBase {
    // ...
  
    Future<analyzer_plugin.EditGetAssistsResult> handleGetAssists(
      ResolvedUnitResult resolvedUnitResult, {
      required int offset,
      required int length,
    }) async {
        // TODO return some assists for the given offset
    }
  }
  

0.0.16

Fix expect_lint not working if the file doesn't contain any lint.

0.0.15

• Custom_lint now has a built-in mechanism for testing lints. Simply write a file that should contain lints for your plugin. Then, using a syntax similar to // ignore, write a // expect_lint: code in the line before your lint:

  // expect_lint: riverpod_final_provider
  var provider = Provider(...);
  

  When doing this, there are two possible cases:

  • The line after the expect_lint correctly contains the expected lint.
    In that case, the lint is ignored (similarly to if we used // ignore)
  • The next line does not contain the lint. In that case, the expect_lint comment will have an error.

  This allows testing your plugins by simply running custom_lint on your test/example folder. Then, if any expected lint is missing, the command will fail. But if your plugin correctly emits the lint, the command will succeed.

• Upgrade analyzer/analzer_plugin

0.0.14

• Fix custom_lint not working in the IDE

0.0.13

• Add debugger and hot-reload support (Thanks to @TimWhiting)
• Correctly respect exclude obtains from the analysis_options.yaml
• Fix dart analyze incorrectly failing due to showing the "plugin is starting" lint.

0.0.12

• Fix custom_lint plugins not working in release mode and when using git dependencies (thanks to @TimWhiting)
• Fix command line exit code not being set properly (thansk to @andrzejchm)

0.0.11

Fix custom_lint not showing in the IDE

0.0.10+1

Update docs

0.0.10

• Upgrade Riverpod to 2.0.0
• Fix deprecation errors with analyzer

0.0.9+1

Update description and readme

0.0.9

• Lint fixes can now be used when placing the cursor on the last character of a lint
• improve pub score

0.0.8

Allow lints to emit fixes

0.0.7

Fix a bug where the custom_lint command line may not list all lints

0.0.6

feat!: getLints now is expected to return a Stream<Lint> instead of Iterable<Lint>

fix: a bug where the lints shown by the IDE could get out of sync with the actual content of the file

0.0.5

Fixed error reporting if a custom_lint plugin throws but the exception comes from a package instead of the plugin itself.

0.0.4

• Fixed a bug where the command line could show IDE-only meant for debugging

0.0.3

PluginBase.getLints now receive a ResolvedUnitResult instead of a LibraryElement.

0.0.2

• Compilation errors are now visible within the pubspec.yaml of applications that are using the plugin.

• Plugins that are currently loading are now highlighted inside the pubspec.yaml of applications that are using the plugin.

• If a plugin throws when trying to analyze a Dart file, the IDE will now show the exception at the top of the analyzed file.

• Compilation errors, exceptions and prints are now accessible within a log file (custom_lint.log) inside applications using the plugin.

0.0.1

Initial release