Merge package:lints

[mosuem]

• Move and fix workflow files, labeler.yaml, and badges in the README.md
• Rev the version of the package, so that pub.dev points to the correct site
• Add a line to the changelog:

* Move to `dart-lang/core` monorepo.

• 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
• 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 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.

[github-actions]

PR Health

Changelog Entry ✔️

Package	Changed Files

Changes to files need to be accounted for in their respective changelogs.

Coverage ⚠️

File	Coverage
pkgs/lints/tool/gen_docs.dart	💔 Not covered
pkgs/lints/tool/validate_lib.dart	💔 Not covered

This check for test coverage is informational (issues shown here will not fail the PR).

This check can be disabled by tagging the PR with skip-coverage-check.

API leaks ✔️

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 ✔️

// 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.

[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.

[devoncarew]

lgtm; note a few in-line edits and a file rename

[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.

[devoncarew]

@mosuem - as of dart-lang/lints#220 this should be unblocked. A few commits have landed in the source repo after this PR was created; I don't know if we want to include them or just recreate this PR.

[mosuem]

I will rerun trebuchet and force-push to this PR.

[github-actions]

Package publishing

Package	Version	Status	Publish tag (post-merge)
package:lints	5.1.1	ready to publish	lints-v5.1.1
package:args	2.6.1-wip	WIP (no publish necessary)
package:async	2.12.0	already published at pub.dev
package:characters	1.4.0	already published at pub.dev
package:collection	1.20.0-wip	WIP (no publish necessary)
package:convert	3.1.2	already published at pub.dev
package:crypto	3.0.6	already published at pub.dev
package:fixnum	1.1.1	already published at pub.dev
package:logging	1.3.0	already published at pub.dev
package:os_detect	2.0.3-wip	WIP (no publish necessary)
package:path	1.9.1	already published at pub.dev
package:platform	3.1.6	already published at pub.dev
package:typed_data	1.4.0	already published at pub.dev

Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.