Consider a static code check for the @GenerateMocks annotation before resolving the library

[evanweible-wf]

Related to #502 and dart-lang/build#3238. Currently, the mock builder is implemented in such a way that it fully resolves every Dart library. Given that this builder also currently runs on all .dart files by default, this results in a significant performance hit, especially for large projects, and especially considering that this builder won't generate any code for most of its inputs.

Consumers can narrow down the inputs to this builder, but it would be nice to improve the performance of this builder by default. One option to do so would be to perform a check for the presence of a @GenerateMocks annotation in the source file's text before using the builder API/analyzer to resolve that library. Even if the check produced false-positives (for example, finding it in a comment), it would better than resolving every library.

[srawlins]

Great suggestion! Do you have any technical details for this idea?

E.g. in the build method, the builder system passes in a BuildStep which has an .inputLibrary, which I believed is a resolved library. Is there something I can do so that build is called less?

[evanweible-wf]

My understanding is that BuildStep.inputLibrary is evaluated lazily, so if you don't access it you won't incur the perf hit of resolving the library. You could start by reading the input's contents as text, check if @GenerateMocks( shows up in the source, and return early if not:

  Future<void> build(BuildStep buildStep) async {
    final source = await buildStep.readAsString(buildStep.inputId);
    if (!source.contains('@GenerateMocks(')) return;
    ...
  }

[natebosch]

Yeah I think it would be sensible to have something like

    if (!(await buildStep.readAsString(buildStep.inputId))
        .contains('GenerateMocks')) {
      return;
    }

[natebosch]

I'm not sure if we currently allow subclassing GenerateMocks or creating const declarations in one library and annotating in another - if we do the library we are generating for wouldn't have that string.

[srawlins]

This would prevent mocks from being built from part files, which is supported today.

I'm not super against removing the support, unless we know of a common pattern.