How to make dart pub global run firehose --validate work with nested projects requiring a pub get?

[dcharkes]

The dart analyze step fails because pub get is not run in any subfolders.

  * `dart analyze` found the following issue(s):
    Analyzing lib, test, pubspec.yaml...
    
      error - test/data/dart_app/bin/dart_app.dart:5:8 - Target of URI doesn't exist: 'package:native_add/native_add.dart'. Try creating the file referenced by the URI, or try using a URI for a file that does exist. - uri_does_not_exist

Full log: https://github.com/dart-lang/native/actions/runs/5795237048/job/15706409172?pr=115

[dcharkes]

Possible fix: make pub get apply to all subfolders: dart-lang/pub#3855

[dcharkes]

Ignoring the folders with analysis_options.yaml does work to fix dart analyze, but not dart pub global run firehose --validate:

analyzer:
  exclude:
    # TODO(https://github.com/dart-lang/ecosystem/issues/150): Remove this.
    - test/data/

[dcharkes]

A workaround would be if we could somehow configure a set of paths to run pub get in.

[dcharkes]

The root cause is likely in pub, not in this package:

• dart pub publish --dry-run analyzes all Dart files with regard to toplevel pubspec.yaml pub#3982

[devoncarew]

We could disable all pub validation (--skip-validation); what I'd really like though is a flag to tell pub publish to not try and run analysis - we're already covering that ourselves in multiple ways.

[sigurdm]

I can see some other solutions:

• allow a pre-publish command to be run, manually invoking dart pub get in the test folder
• avoid having an actual project in test-data. One solution could be to create the project in a sandbox from inside the test itself.

[dcharkes]

• avoid having an actual project in test-data. One solution could be to create the project in a sandbox from inside the test itself.

That's unpractical when test projects get somewhat complicated, you want the actual test projects to exist and be valid projects. We could have them as strings, or have a non .dart extension and copy them, or use analysis ignore, but that makes maintaining test projects hard.

Either skipping validation or having a custom command would work. For the custom command, we would need to somehow pipe that through from the ci.yaml via firehose. As Devon said, we already do analysis on the CI, so skipping analysis seems like the better option.