add several rules to core and recommended

[devoncarew]

• add no_wildcard_variable_uses, secure_pubspec_urls, and type_literal_in_constant_pattern to core
• add deprecated_consistency, unnecessary_to_list_in_spreads, and use_super_parameters to recommended
• remove prefer_equal_for_default_values from recommended

Keeping the version at 3.0.0-wip.

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[natebosch]

Do we need to double check the behavior around class/constructor deprecation?

[natebosch]

I confirmed that the lint does currently ask for constructors to be deprecated when the class is deprecated - I think we had discussed changing that.

I do notice that this requirement does impact what deprecations you see on usage of a type alias - if a constructor is not deprecated then usage of that constructor through an alias is not flagged with a diagnostic.

@deprecated
class C {
  C();
  @deprecated
  C.namedDeprecated();
}

typedef Renamed = C;

void main() {
  Renamed(); // No diagnostic
  Renamed.namedDeprecated(); // Diagnostic

[devoncarew]

Yup, good catch. It looks like @pq has investigated this in dart-lang/linter#4752 and we're free to remove the requirement (from the lint) to deprecate both the class and the ctor.

Let's delay adding this lint to the set until we've shipped an SDK w/ that update for the lint; I'll remove from this PR and update the github project.

[pq]

Ah. This is interesting.

One thing to note is that you should see a diagnostic on the typedef declaration.

typedef Renamed = C; // Diagnostic

But you're right that you won't see it on Renamed().

I guess in practice if you exported the typedef maybe this could be a footgun for users but then you've made a conscious choice to ignore the diagnostic reported at the typedef declaration so maybe that's on you? Not sure what the right answer is... 🤔