Merge `package:lints`

[mosuem]

• [x] Move and fix workflow files, labeler.yaml, and badges in the README.md

• [x] Rev the version of the package, so that pub.dev points to the correct site

• [x] Add a line to the changelog:

• Move to dart-lang/core monorepo.

• [x] Add the package to the top-level readme of the monorepo:

  | [lints](pkgs/lints/) | Official Dart lint rules. Defines the 'core' and 'recommended' set of lints suggested by the Dart team.
  | [![pub package](https://img.shields.io/pub/v/lints.svg)](https://pub.dev/packages/lints) |

• [ ] Important! Merge the PR with 'Create a merge commit' (enabling then disabling the Allow merge commits admin setting)

• [ ] Add the lints project to this repo

• [ ] Update the auto-publishing settings on https://pub.dev/packages/lints/admin

• [x] Add the following text to https://github.com/dart-lang/lints/:'

> [!IMPORTANT]  
> This repo has moved to https://github.com/dart-lang/core/tree/main/pkgs/lints

• [ ] Publish using the autopublish workflow
• [ ] Push tags to GitHub using git tag --list 'lints*' | xargs git push origin
• [ ] Close open PRs in dart-lang/lints with the following message:

Closing as the [dart-lang/lints](https://github.com/dart-lang/lints) repository is merged into the [dart-lang/core](https://github.com/dart-lang/core) monorepo. Please re-open this PR there!

• [ ] Transfer issues by running dart run pkgs/repo_manage/bin/report.dart transfer-issues --source-repo dart-lang/lints --target-repo dart-lang/core --add-label package:lints --apply-changes
• [ ] Archive https://github.com/dart-lang/lints/

---

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

Contribution guidelines:

- See our [contributor guide](https://github.com/dart-lang/.github/blob/main/CONTRIBUTING.md) 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](https://dart.dev/guides/language/effective-dart) and use `dart format`. - Most changes should add an entry to the changelog and may need to [rev the pubspec package version](https://github.com/dart-lang/sdk/blob/main/docs/External-Package-Maintenance.md#making-a-change). - Changes to packages require [corresponding tests](https://github.com/dart-lang/.github/blob/main/CONTRIBUTING.md#Testing). Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[github-actions[bot]]

PR Health

Changelog Entry :heavy_check_mark:

| Package | Changed Files | | :--- | :--- | Changes to files need to be [accounted for](https://github.com/dart-lang/ecosystem/wiki/Changelog) in their respective changelogs.

Coverage :heavy_check_mark:

| File | Coverage | | :--- | :--- | This check for [test coverage](https://github.com/dart-lang/ecosystem/wiki/Test-Coverage) is informational (issues shown here will not fail the PR).

API leaks :heavy_check_mark:

The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API. | Package | Leaked API symbols | | :--- | :--- |

License Headers :heavy_check_mark:

``` // Copyright (c) 2024, the Dart project authors. Please see the AUTHORS file // for details. All rights reserved. Use of this source code is governed by a // BSD-style license that can be found in the LICENSE file. ``` | Files | | :--- | | _no missing headers_ | All source files should start with a [license header](https://github.com/dart-lang/ecosystem/wiki/License-Header).

[mosuem]

Should this package not be auto-published? @devoncarew

[devoncarew]

Should this package not be auto-published? @devoncarew

I think it's fine to auto-publish. We will want to upgrade our publishing automation a bit; with many packages living in a repo, we'll want to have some precision about which commits we publish from (i.e., not just the head commit). I'll open an issue for that.

[mosuem]

I think it's fine to auto-publish. We will want to upgrade our publishing automation a bit; with many packages living in a repo, we'll want to have some precision about which commits we publish from (i.e., not just the head commit). I'll open an issue for that.

I am asking because the publish workflow is failing because of the dependency on a pre-release SDK version, and I don't know how SDK versioning is handled with package:lints.

[devoncarew]

I am asking because the publish workflow is failing because of the dependency on a pre-release SDK version, and I don't know how SDK versioning is handled with package:lints.

Ah, I see;

Package validation found the following potential issue: 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.6.0-0, consider publishing the package as a pre-release instead.

And once this package is in a monorepo, every PR will need to apply a label to ignore failures from the publishing bot. That's a bit annoying.

We could either solve that - allow per-package configuration of publishing validation - or delay adding this package to the monorepo until after the next stable sdk release. We don't typically need to depend on a pre-release sdk for package:lints.