[flutter_lints] version 2.0

[goderbauer]

See https://github.com/dart-lang/lints/projects/1.

Fixes dart-lang/core#763
Fixes dart-lang/core#769

Depends on dart-archive/lints#72. Do not merge until that change is published. (Tests will also fail until then.)

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

[goderbauer]

/cc @mit @pq @srawlins

[goderbauer]

@christopherfujino Can you grant a test exception for this? There isn't really any code to test...

[christopherfujino]

test-exempt: configuration change that will effect downstream tests.

[pq]

👍

[mit-mit]

I tried to use the new super-dot language feature from 2.17 in a widget:

That triggers the key lint:

class OtherWidget extends StatelessWidget {
  const OtherWidget({super.key});

  @override
  Widget build(BuildContext context) {
    return Container(
      
    );
  }
}

   info • Use key in widget constructors • lib/widgets.dart:6:3 • use_key_in_widget_constructors

Can we remove that lint?

Filed flutter/flutter#100297 to track

[goderbauer]

Can we remove that lint?

I would prefer fixing the lint since it's not a new lint added by this PR. Looks like @pq has a fix out in dart-archive/linter#3295. Will that one make the cut for 2.17?

[pq]

Will that one make the cut for 2.17?

It should. As soon as I land the fix, I'll work on a new release. (That has some other super-parameter related fixes too.)

[goderbauer]

The publishable check is failing with

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 2.17.0-0, consider publishing the package as a pre-release instead.
  See https://dart.dev/tools/pub/publishing#publishing-prereleases For more information on pre-releases.

This warning is actually expected and can be ignored as described in https://dart.dev/tools/pub/publishing#publishing-previews. What's described there is exactly what we want to do here...

I don't know how to submit this, though, without turning the entire tree red because of this warning. I don't want to disable the check altogether...

@stuartmorgan Do you maybe have a suggestion?

[goderbauer]

Looks like flutter_plugin_tools already has a allow-pre-release flag. I don't think I want to turn that on for all packages. Maybe we should extend the flag to allow specifying package names for which pre-releases are allowed and then specify this one for it? Or would it be ok to have this on for all packages in this repository?

[stuartmorgan]

I think it would be fine to turn it on for the whole repo. The background is that we originally added the support unconditionally for NNBD, then when we finished that transition we kept the code around in case we needed it again, but put it behind a flag since we didn't have an actual use case in mind.

I think we can start with the easiest thing, which is turning the flag on, and then revisit whether we need to add package-level targeting if we see issues in practice.

[goderbauer]

Cool. I will make it so. Thanks!

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group.