Custom lints don't update when used with `dart analysis_server` command

[pattobrien]

Reproducible example here: https://github.com/pattobrien/custom_lint_lsp_bug

Steps to Reproduce

1. Run dart example/tool/lsp_client.dart to start LSP server.
2. Wait for built-in lint to show, as well as custom_lint.
3. Comment out code in example/lib/example.dart, line-by-line.

NOTE: the code in tool/lsp_client.dart is copied directly from the analysis_server_client example in the Dart SDK repo.

Observed Result

Both the built-in deprecation lint, as well as the custom_lint are seen on first load.

From that point onwards, if you comment out the deprecation code (which triggers the built-in Dart lints), you will observe the list of issues in the terminal DOES change.

However, if you try the same with the custom_lint, the list of lints NEVER changes. In other words, stale diagnostics will always be displayed, until the LSP server is restarted.

Of course, this isn't observed in e.g. VSCode IDE (using Dart extension) - but I'm unsure what could be causing this descrepency.

[DanTup]

I looked into this, and the problem is that the watch events are not passed to the plugin because they do not match the interestingFiles glob defined by the plugin. This is defined as * here:

https://github.com/invertase/dart_custom_lint/blob/3aaed0c7ed283c1c4e4702d38e4200f1526c14a0/packages/custom_lint/lib/src/v2/custom_lint_analyzer_plugin.dart#L330

But the glob is checked against the whole file path, and the docs for the glob say:

///   * '*' matches one or more characters except '/'.
///   * '?' matches exactly one character except '/'.
///   * '**' matches one or more characters including '/'.

If I update that line to instead have ** then the lints update correctly when the file is modified on disk.

[rrousselGit]

^ A bit late to the topic but fwiw I tried using ** and still had the issue.

[DanTup]

@rrousselGit do you have a reproducible sample? When I tested with the repro above, using ** resolved the issue for me. I'm not sure if you tested the same repro above, or you might be hitting a slightly different case?