Support being able to ignore some pub publish --dry-run warnings

[devoncarew]

As we roll out more automation around publishing packages we've hit a few hiccups wrt automated package validation. Specifically, we generally run dart pub publish --dry-run as part of PR validation, and fail the PR if the dry run reports any issues.

Problems arise when the validation failures are intentional; for instance, a tight constraint on another package, or, publishing using a pre-release SDK. We still want to do general publishing validation - we'd like to run most of the consistently checks. But we'd like to ignore specific ones (a blanket 'ignore-all-issues' - or not running the validation at all - could hide problems we would want to know about).

A potential option here is to support 'ignore' comment syntax in pubspec files. So something like:

# ignore_for_file: tight_version_contraints
# ignore_for_file: pre_release_publishing

name: foo_package
...

Additional context:

• https://github.com/dart-lang/ecosystem/issues/64
• https://github.com/dart-lang/ecosystem/issues/75
• https://github.com/dart-lang/webdev/pull/2002

And some sample validation failures:

* Your dependency on "dwds" should allow more than one version. For example:
  dependencies:
    dwds: ^18.0.0
  Constraints that are too tight will make it difficult for people to use your package
  along with other packages that also depend on "dwds".

* Packages with an SDK constraint on a pre-release of the Dart SDK should themselves be published as a pre-release version. If this package needs Dart version 3.0.0-188.0.dev, consider publishing the package as a pre-release instead.
  See https://dart.dev/tools/pub/publishing#publishing-prereleases For more information on pre-releases.

[sigurdm]

Related to https://github.com/dart-lang/pub/issues/2535 .

[fulpismo]

@sigurdm just a concern i'm currently having... is it expected to treat common infos as fatal in a publish analyze?

[sigurdm]

@devoncarew we now have dart pub publish --skip-validation as a generic escape hatch, and pub no longer treats infos as fatal.

Do we still need being able to ignore specific validations?

[devoncarew]

we now have dart pub publish --skip-validation as a generic escape hatch

Hmm, I opened this issue mostly in the context of dart pub publish --dry-run (not a general publish). We want to know about issues we're not aware of, but be able to ignore specific things for some packages - places where they know they're doing things a dry-run publish would complain about.

pub no longer treats infos as fatal.

Which things pub publish reports about are infos?

[sigurdm]

Which things pub publish reports about are infos?

We used to have the validation run dart analyze --fatal-infos and give a warning in case it returned non-zero. (The thinking being that package-authors ought to go the last bit before publishing.

But we ended up undoing that. (The thinking now being that pub by default should follow the default of the analyzer, and not take any further opinion.)

Besides that pub publish itself has three severities of validations:

• error -> won't publish
• warning -> allows publishing, but --dry-run returns non-zero
• hint -> --dry-run still returns zero Current hints are:
  • If you have non-dev-dependency overrides.
  • If you are not publishing a version newer than all existing versions
  • If your version number is not an increment of any existing version (like if you skip a version number)
  • If you are going from a non-null-safety to a null-safety version.
  • If you have an sdk-constraint like >=2.12.0 <3.0.0, you are hinted to change it to >2.12.0 <4.0.0.

I think we want to go towards a world where more of the validations are handled by the analyzer. That provides faster feedback, and leverages mechanics like // ignore lines, then we would mainly have the validation running dart analyze. We are still some way from that.

[rishabhsharma3617]

I highly support this demand , right now we are using some tight constrains in versions of deps since all our packages are internal built . It will be so good if we can ignore some warnings , its giving me a failure in pipeline because of warnings :(

[joecotton-wk]

Bumping. We have a project that is blocked by #3789 . Having something like this would allow us to ignore the .gitignore errors while still notifying us of other issues. The --skip-validation flag is too generic; we don't want to skip all checks, just one.