Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove a pub publish warning, or make the warnings configurable per-package #4484

Open
devoncarew opened this issue Jan 7, 2025 · 2 comments
Labels
type-enhancement A request for a change that isn't a bug

Comments

@devoncarew
Copy link
Member

We encountered this publish warning in our publishing automation (context):

 Package validation found the following potential issue:
  * The name of "lib/builder.dart", "builder", should match the name of the package, "shelf_router_generator".
    This helps users know what library to import.

This is for a package where we do want to use lib/builder.dart for the entry-point instead of lib/shelf_router_generator.dart as the warning would suggest.

Can we either:

  • remove this warning from the set we generate (false positives are expensive), or
  • make warnings configurable per-package, so a package can intentional suppress them?

The configuration might be done in a section of the pubspec file or in some other durable location. Thanks!

@sigurdm sigurdm added the type-enhancement A request for a change that isn't a bug label Jan 9, 2025
@sigurdm
Copy link
Contributor

sigurdm commented Jan 9, 2025

Yeah - publication warnings are not very ergonomic.

I am a bit wary of building a way of ignoring specific warnings, as that would involve quite some formalization of the set of warnings. (not saying it is bad, just a big task).

I wonder if we could push this warning into the analyzer as a hint/lint. The analyzer already has the // ignore: mechanism in place, and we run dart analyze as a publication validation step.

The rule is implemented here:

if (libraries.length == 1) {

If there is only a single exposed library, we want it to be named the same as the package.

I think this is usually right, and maintains a somewhat nice convention (though personally I would have preferred a fixed name for the main library, but that is too late).

@pq do you think this would work as a hint/lint/warning?

We could also downgrade this warning to an "info", such that it doesn't block the upload, but it might still be seen by enough uploaders that it has some merit.

@jonasfj might have opinions when he is back

@pq
Copy link
Member

pq commented Jan 9, 2025

do you think this would work as a hint/lint/warning?

I think so. We have a file_names lint that enforces lowercase_with_underscores so there's precedent in hanging diagnostics off the first offset in a file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

3 participants