+{% assign sorted_terms = glossary | sort: "term" %}
{% for term in sorted_terms -%}
{% assign cardId = term.id | default: term.term | slugify -%}
{% assign contentId = cardId | append: '-content' -%}
-
+
+
From d641ec326a4d5319d525caffe8bafb9072fdc661 Mon Sep 17 00:00:00 2001
From: Sigurd Meldgaard
Date: Fri, 28 Feb 2025 22:54:30 +0100
Subject: [PATCH 3/5] Document the `pubspec_overrides.yaml` file (#6462)
Resolves https://github.com/dart-lang/site-www/issues/5019
---------
Co-authored-by: Jonas Finnemann Jensen
Co-authored-by: Parker Lougheed
---
firebase.json | 1 +
src/content/tools/pub/dependencies.md | 27 +++++++++++++++++++++++++
src/content/tools/pub/package-layout.md | 17 +++++++++++-----
3 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/firebase.json b/firebase.json
index 144e97f535..e50240d7ec 100644
--- a/firebase.json
+++ b/firebase.json
@@ -387,6 +387,7 @@
{ "source": "/to/pub-workspaces", "destination": "/tools/pub/workspaces", "type": 301 },
{ "source": "/to/publish-from-github", "destination": "/tools/pub/automated-publishing#publishing-packages-using-github-actions", "type": 301 },
{ "source": "/to/publish-with-service-account", "destination": "/tools/pub/automated-publishing#publishing-from-google-cloud-build", "type": 301 },
+ { "source": "/to/pubspec-overrides", "destination": "/tools/pub/dependencies#pubspec-overrides", "type": 301 },
{ "source": "/to/sdk-constraint", "destination": "/tools/pub/pubspec#sdk-constraints", "type": 301 },
{ "source": "/to/sdk-version-pinning", "destination": "https://github.com/dart-lang/sdk/blob/main/docs/Flutter-Pinned-Packages.md", "type": 301 },
{ "source": "/to/web-debug-extension", "destination": "https://chromewebstore.google.com/detail/dart-debug-extension/eljbmlghnomdjgdjmbdekegdkbabckhm", "type": 301 },
diff --git a/src/content/tools/pub/dependencies.md b/src/content/tools/pub/dependencies.md
index fea5a532a5..684f19cf2c 100644
--- a/src/content/tools/pub/dependencies.md
+++ b/src/content/tools/pub/dependencies.md
@@ -432,6 +432,32 @@ As a result, if you publish a package to pub.dev,
keep in mind that your package's dependency overrides
are ignored by all users of your package.
+If you are using a [pub workspace][workspaces],
+you can have `dependency_overrides` in each workspace package, but
+a single package can only be overridden once in the workspace.
+
+## `pubspec_overrides.yaml` {:#pubspec-overrides}
+
+If you want to change certain aspects of
+the resolution of your `pubspec.yaml` file, but
+do not want to change the actual file, you can
+place a file named `pubspec_overrides.yaml` next to the `pubspec.yaml`.
+
+Attributes from that file will override those from `pubspec.yaml`.
+
+The properties that can be overridden are:
+
+* `dependency_overrides`
+* `workspace`
+* `resolution`
+
+This can be useful to avoid accidentally
+checking temporary overrides in to version control.
+It can also make it easier to generate overrides from a script.
+
+In a [pub workspace][workspaces], each workspace package
+can have a `pubspec_overrides.yaml` file.
+
## Best practices
Be proactive in managing your dependencies.
@@ -570,3 +596,4 @@ to differentiate versions. ↩
[`dart pub upgrade`]: /tools/pub/cmd/pub-upgrade
[pubsite]: {{site.pub}}
[semantic versioning specification]: https://semver.org/spec/v2.0.0-rc.1.html
+[workspaces]: /tools/pub/workspaces
diff --git a/src/content/tools/pub/package-layout.md b/src/content/tools/pub/package-layout.md
index 045c96d324..a30eb2537c 100644
--- a/src/content/tools/pub/package-layout.md
+++ b/src/content/tools/pub/package-layout.md
@@ -25,7 +25,8 @@ might look like:
enchilada/
.dart_tool/ *
pubspec.yaml
- pubspec.lock **
+ pubspec_overrides.yaml **
+ pubspec.lock ***
LICENSE
README.md
CHANGELOG.md
@@ -34,7 +35,7 @@ enchilada/
bin/
enchilada
doc/
- api/ ***
+ api/ ****
getting_started.md
example/
main.dart
@@ -58,22 +59,28 @@ enchilada/
index.html
main.dart
style.css
-```
+```
\* The `.dart_tool/` directory exists after you've run `dart pub get`.
Don't check it into source control.
To learn more, see
[Project specific caching for tools](#project-specific-caching-for-tools).
-\** The `pubspec.lock` file exists after you've run `dart pub get`.
+\** The [`pubspec_overrides.yaml`][] file,
+ if present, overrides certain aspects of `pubspec.yaml`.
+ Usually you don't want to check it into source control.
+
+\*** The `pubspec.lock` file exists after you've run `dart pub get`.
Leave it out of source control unless your package is an
[application package](/tools/pub/glossary#application-package).
-\*** The `doc/api` directory exists locally after you've run
+\**** The `doc/api` directory exists locally after you've run
[`dart doc`](/tools/dart-doc).
Don't check the `api` directory into source control.
+[`pubspec_overrides.yaml`]: /tools/pub/dependencies#pubspec-overrides
+
## The pubspec
```plaintext
From 90e6a77ce23532c1691fcca9f32020dd72c11b61 Mon Sep 17 00:00:00 2001
From: Parker Lougheed
Date: Fri, 28 Feb 2025 17:35:56 -0600
Subject: [PATCH 4/5] Update diagnostic and lint docs from SDK (#6467)
These are written and reviewed in the SDK so do not need to be
rereviewed.
---
src/_data/linter_rules.json | 25 +++++----
src/_data/site.yml | 2 +-
src/content/language/built-in-types.md | 2 +-
src/content/tools/diagnostic-messages.md | 71 +++++++++++++++++++++---
4 files changed, 80 insertions(+), 20 deletions(-)
diff --git a/src/_data/linter_rules.json b/src/_data/linter_rules.json
index d5138c9f8f..71bfabd2a3 100644
--- a/src/_data/linter_rules.json
+++ b/src/_data/linter_rules.json
@@ -320,7 +320,7 @@
"incompatible": [],
"sets": [],
"fixStatus": "noFix",
- "details": "**AVOID** using `FutureOr` as the type of a result. This type is\nproblematic because it may appear to encode that a result is either a\n`Future`, or the result should be discarded (when it is `void`).\nHowever, there is no safe way to detect whether we have one or the other\ncase (because an expression of type `void` can evaluate to any object\nwhatsoever, including a future of any type).\n\nIt is also conceptually unsound to have a type whose meaning is something\nlike \"ignore this object; also, take a look because it might be a future\".\n\nAn exception is made for contravariant occurrences of the type\n`FutureOr` (e.g., for the type of a formal parameter), and no\nwarning is emitted for these occurrences. The reason for this exception\nis that the type does not describe a result, it describes a constraint\non a value provided by others. Similarly, an exception is made for type\nalias declarations, because they may well be used in a contravariant\nposition (e.g., as the type of a formal parameter). Hence, in type alias\ndeclarations, only the type parameter bounds are checked.\n\nA replacement for the type `FutureOr` which is often useful is\n`Future?`. This type encodes that the result is either a\n`Future` or it is null, and there is no ambiguity at run time\nsince no object can have both types.\n\nIt may not always be possible to use the type `Future?` as a\nreplacement for the type `FutureOr`, because the latter is a\nsupertype of all types, and the former is not. In this case it may be a\nuseful remedy to replace `FutureOr` by the type `void`.\n\n**BAD:**\n```dart\nFutureOr m() {...}\n```\n\n**GOOD:**\n```dart\nFuture? m() {...}\n```\n\n**This rule is experimental.** It is being evaluated, and it may be changed\nor removed. Feedback on its behavior is welcome! The main issue is here:\nhttps://github.com/dart-lang/linter/issues/4622",
+ "details": "**AVOID** using `FutureOr` as the type of a result. This type is\nproblematic because it may appear to encode that a result is either a\n`Future`, or the result should be discarded (when it is `void`).\nHowever, there is no safe way to detect whether we have one or the other\ncase (because an expression of type `void` can evaluate to any object\nwhatsoever, including a future of any type).\n\nIt is also conceptually unsound to have a type whose meaning is something\nlike \"ignore this object; also, take a look because it might be a future\".\n\nAn exception is made for contravariant occurrences of the type\n`FutureOr` (e.g., for the type of a formal parameter), and no\nwarning is emitted for these occurrences. The reason for this exception\nis that the type does not describe a result, it describes a constraint\non a value provided by others. Similarly, an exception is made for type\nalias declarations, because they may well be used in a contravariant\nposition (e.g., as the type of a formal parameter). Hence, in type alias\ndeclarations, only the type parameter bounds are checked.\n\nA replacement for the type `FutureOr` which is often useful is\n`Future?`. This type encodes that the result is either a\n`Future` or it is null, and there is no ambiguity at run time\nsince no object can have both types.\n\nIt may not always be possible to use the type `Future?` as a\nreplacement for the type `FutureOr`, because the latter is a\nsupertype of all types, and the former is not. In this case it may be a\nuseful remedy to replace `FutureOr` by the type `void`.\n\n**BAD:**\n```dart\nFutureOr m() {...}\n```\n\n**GOOD:**\n```dart\nFuture? m() {...}\n```\n\n**This rule is experimental.** It is being evaluated, and it may be changed\nor removed. Feedback on its behavior is welcome! The main issue is here:\nhttps://github.com/dart-lang/sdk/issues/59232.",
"sinceDartSdk": "3.6"
},
{
@@ -791,7 +791,7 @@
"incompatible": [],
"sets": [],
"fixStatus": "noFix",
- "details": "**DO** invoke `cancel` on instances of `dart:async` `StreamSubscription`.\n\nCancelling instances of StreamSubscription prevents memory leaks and unexpected\nbehavior.\n\n**BAD:**\n```dart\nclass A {\n StreamSubscription _subscriptionA; // LINT\n void init(Stream stream) {\n _subscriptionA = stream.listen((_) {});\n }\n}\n```\n\n**BAD:**\n```dart\nvoid someFunction() {\n StreamSubscription _subscriptionF; // LINT\n}\n```\n\n**GOOD:**\n```dart\nclass B {\n StreamSubscription _subscriptionB; // OK\n void init(Stream stream) {\n _subscriptionB = stream.listen((_) {});\n }\n\n void dispose(filename) {\n _subscriptionB.cancel();\n }\n}\n```\n\n**GOOD:**\n```dart\nvoid someFunctionOK() {\n StreamSubscription _subscriptionB; // OK\n _subscriptionB.cancel();\n}\n```\n\n**Known limitations**\n\nThis rule does not track all patterns of StreamSubscription instantiations and\ncancellations. See [linter#317](https://github.com/dart-lang/linter/issues/317)\nfor more information.",
+ "details": "**DO** invoke `cancel` on instances of `dart:async` `StreamSubscription`.\n\nCancelling instances of StreamSubscription prevents memory leaks and unexpected\nbehavior.\n\n**BAD:**\n```dart\nclass A {\n StreamSubscription _subscriptionA; // LINT\n void init(Stream stream) {\n _subscriptionA = stream.listen((_) {});\n }\n}\n```\n\n**BAD:**\n```dart\nvoid someFunction() {\n StreamSubscription _subscriptionF; // LINT\n}\n```\n\n**GOOD:**\n```dart\nclass B {\n StreamSubscription _subscriptionB; // OK\n void init(Stream stream) {\n _subscriptionB = stream.listen((_) {});\n }\n\n void dispose(filename) {\n _subscriptionB.cancel();\n }\n}\n```\n\n**GOOD:**\n```dart\nvoid someFunctionOK() {\n StreamSubscription _subscriptionB; // OK\n _subscriptionB.cancel();\n}\n```\n\n**Known limitations**\n\nThis rule does not track all patterns of StreamSubscription instantiations and\ncancellations. See [linter#317](https://github.com/dart-lang/sdk/issues/57387)\nfor more information.",
"sinceDartSdk": "2.0"
},
{
@@ -833,7 +833,7 @@
"incompatible": [],
"sets": [],
"fixStatus": "noFix",
- "details": "**DO** invoke `close` on instances of `dart:core` `Sink`.\n\nClosing instances of Sink prevents memory leaks and unexpected behavior.\n\n**BAD:**\n```dart\nclass A {\n IOSink _sinkA;\n void init(filename) {\n _sinkA = File(filename).openWrite(); // LINT\n }\n}\n```\n\n**BAD:**\n```dart\nvoid someFunction() {\n IOSink _sinkF; // LINT\n}\n```\n\n**GOOD:**\n```dart\nclass B {\n IOSink _sinkB;\n void init(filename) {\n _sinkB = File(filename).openWrite(); // OK\n }\n\n void dispose(filename) {\n _sinkB.close();\n }\n}\n```\n\n**GOOD:**\n```dart\nvoid someFunctionOK() {\n IOSink _sinkFOK; // OK\n _sinkFOK.close();\n}\n```\n\n**Known limitations**\n\nThis rule does not track all patterns of Sink instantiations and\nclosures. See [linter#1381](https://github.com/dart-lang/linter/issues/1381)\nfor more information.",
+ "details": "**DO** invoke `close` on instances of `dart:core` `Sink`.\n\nClosing instances of Sink prevents memory leaks and unexpected behavior.\n\n**BAD:**\n```dart\nclass A {\n IOSink _sinkA;\n void init(filename) {\n _sinkA = File(filename).openWrite(); // LINT\n }\n}\n```\n\n**BAD:**\n```dart\nvoid someFunction() {\n IOSink _sinkF; // LINT\n}\n```\n\n**GOOD:**\n```dart\nclass B {\n IOSink _sinkB;\n void init(filename) {\n _sinkB = File(filename).openWrite(); // OK\n }\n\n void dispose(filename) {\n _sinkB.close();\n }\n}\n```\n\n**GOOD:**\n```dart\nvoid someFunctionOK() {\n IOSink _sinkFOK; // OK\n _sinkFOK.close();\n}\n```\n\n**Known limitations**\n\nThis rule does not track all patterns of Sink instantiations and\nclosures. See [sdk#57882](https://github.com/dart-lang/sdk/issues/57882)\nfor more information.",
"sinceDartSdk": "2.0"
},
{
@@ -876,7 +876,7 @@
"incompatible": [],
"sets": [],
"fixStatus": "hasFix",
- "details": "**DO** reference only in-scope identifiers in doc comments.\n\nIf you surround identifiers like variable, method, or type names in square\nbrackets, then tools like your IDE and\n[`dart doc`](https://dart.dev/tools/dart-doc) can link to them. For this to\nwork, ensure that all identifiers in docs wrapped in brackets are in scope.\n\nFor example, assuming `outOfScopeId` is out of scope:\n\n**BAD:**\n```dart\n/// Returns whether [value] is larger than [outOfScopeId].\nbool isOutOfRange(int value) { ... }\n```\n\n**GOOD:**\n```dart\n/// Returns the larger of [a] or [b].\nint max_int(int a, int b) { ... }\n```\n\nNote that the square bracket comment format is designed to allow comments to\nrefer to declarations using a fairly natural format but does not allow\n*arbitrary expressions*. In particular, code references within square brackets\ncan consist of any of the following:\n\n- A bare identifier which is in-scope for the comment (see the spec for what is\n \"in-scope\" in doc comments). Examples include `[print]` and `[Future]`.\n- Two identifiers separated by a period (a \"prefixed identifier\"), such that the\n first identifier acts as a namespacing identifier, such as a class property\n name or method name prefixed by the containing class's name, or a top-level\n identifier prefixed by an import prefix. Examples include `[Future.new]` (an\n unnamed constructor), `[Future.value]` (a constructor), `[Future.wait]` (a\n static method), `[Future.then]` (an instance method), `[math.max]` (given that\n 'dart:async' is imported with a `max` prefix).\n- A prefixed identifier followed by a pair of parentheses, used to disambiguate\n named constructors from instance members (whose names are allowed to collide).\n Examples include `[Future.value()]`.\n- Three identifiers separated by two periods, such that the first identifier is\n an import prefix name, the second identifier is a top-level element like a\n class or an extension, and the third identifier is a member of that top-level\n element. Examples include `[async.Future.then]` (given that 'dart:async' is\n imported with an `async` prefix).\n\n**Known limitations**\n\nThe `comment_references` lint rule aligns with the Dart analyzer's notion of\ncomment references, which is occasionally distinct from Dartdoc's notion of\ncomment references. The lint rule may report comment references which Dartdoc\ncan resolve, even though the analyzer cannot. See\n[linter#1142](https://github.com/dart-lang/linter/issues/1142) for more\ninformation.",
+ "details": "**DO** reference only in-scope identifiers in doc comments.\n\nIf you surround identifiers like variable, method, or type names in square\nbrackets, then tools like your IDE and\n[`dart doc`](https://dart.dev/tools/dart-doc) can link to them. For this to\nwork, ensure that all identifiers in docs wrapped in brackets are in scope.\n\nFor example, assuming `outOfScopeId` is out of scope:\n\n**BAD:**\n```dart\n/// Returns whether [value] is larger than [outOfScopeId].\nbool isOutOfRange(int value) { ... }\n```\n\n**GOOD:**\n```dart\n/// Returns the larger of [a] or [b].\nint max_int(int a, int b) { ... }\n```\n\nNote that the square bracket comment format is designed to allow comments to\nrefer to declarations using a fairly natural format but does not allow\n*arbitrary expressions*. In particular, code references within square brackets\ncan consist of any of the following:\n\n- A bare identifier which is in-scope for the comment (see the spec for what is\n \"in-scope\" in doc comments). Examples include `[print]` and `[Future]`.\n- Two identifiers separated by a period (a \"prefixed identifier\"), such that the\n first identifier acts as a namespacing identifier, such as a class property\n name or method name prefixed by the containing class's name, or a top-level\n identifier prefixed by an import prefix. Examples include `[Future.new]` (an\n unnamed constructor), `[Future.value]` (a constructor), `[Future.wait]` (a\n static method), `[Future.then]` (an instance method), `[math.max]` (given that\n 'dart:async' is imported with a `max` prefix).\n- A prefixed identifier followed by a pair of parentheses, used to disambiguate\n named constructors from instance members (whose names are allowed to collide).\n Examples include `[Future.value()]`.\n- Three identifiers separated by two periods, such that the first identifier is\n an import prefix name, the second identifier is a top-level element like a\n class or an extension, and the third identifier is a member of that top-level\n element. Examples include `[async.Future.then]` (given that 'dart:async' is\n imported with an `async` prefix).\n\n**Known limitations**\n\nThe `comment_references` lint rule aligns with the Dart analyzer's notion of\ncomment references, which is occasionally distinct from Dartdoc's notion of\ncomment references. The lint rule may report comment references which Dartdoc\ncan resolve, even though the analyzer cannot. See\n[sdk#57783](https://github.com/dart-lang/sdk/issues/57783) for more\ninformation.",
"sinceDartSdk": "2.0"
},
{
@@ -1708,7 +1708,7 @@
],
"sets": [],
"fixStatus": "hasFix",
- "details": "Don't type annotate initialized local variables when the type is obvious.\n\nLocal variables, especially in modern code where functions tend to be small,\nhave very little scope. Omitting the type focuses the reader's attention on the\nmore important *name* of the variable and its initialized value. Hence, local\nvariable type annotations that are obvious should be omitted.\n\n**BAD:**\n```dart\nList> possibleDesserts(Set pantry) {\n List> desserts = >[];\n for (final List recipe in cookbook) {\n if (pantry.containsAll(recipe)) {\n desserts.add(recipe);\n }\n }\n\n return desserts;\n}\n\nconst cookbook = >[....];\n```\n\n**GOOD:**\n```dart\nList> possibleDesserts(Set pantry) {\n var desserts = >[];\n for (final List recipe in cookbook) {\n if (pantry.containsAll(recipe)) {\n desserts.add(recipe);\n }\n }\n\n return desserts;\n}\n\nconst cookbook = >[....];\n```\n\nSometimes the inferred type is not the type you want the variable to have. For\nexample, you may intend to assign values of other types later. You may also\nwish to write a type annotation explicitly because the type of the initializing\nexpression is non-obvious and it will be helpful for future readers of the\ncode to document this type. Or you may wish to commit to a specific type such\nthat future updates of dependencies (in nearby code, in imports, anywhere)\nwill not silently change the type of that variable, thus introducing\ncompile-time errors or run-time bugs in locations where this variable is used.\nIn those cases, go ahead and annotate the variable with the type you want.\n\n**GOOD:**\n```dart\nWidget build(BuildContext context) {\n Widget result = someGenericFunction(42) ?? Text('You won!');\n if (applyPadding) {\n result = Padding(padding: EdgeInsets.all(8.0), child: result);\n }\n return result;\n}\n```\n\n**This rule is experimental.** It is being evaluated, and it may be changed\nor removed. Feedback on its behavior is welcome! The main issue is here:\nhttps://github.com/dart-lang/linter/issues/3480.",
+ "details": "Don't type annotate initialized local variables when the type is obvious.\n\nLocal variables, especially in modern code where functions tend to be small,\nhave very little scope. Omitting the type focuses the reader's attention on the\nmore important *name* of the variable and its initialized value. Hence, local\nvariable type annotations that are obvious should be omitted.\n\n**BAD:**\n```dart\nList> possibleDesserts(Set pantry) {\n List> desserts = >[];\n for (final List recipe in cookbook) {\n if (pantry.containsAll(recipe)) {\n desserts.add(recipe);\n }\n }\n\n return desserts;\n}\n\nconst cookbook = >[....];\n```\n\n**GOOD:**\n```dart\nList> possibleDesserts(Set pantry) {\n var desserts = >[];\n for (final List recipe in cookbook) {\n if (pantry.containsAll(recipe)) {\n desserts.add(recipe);\n }\n }\n\n return desserts;\n}\n\nconst cookbook = >[....];\n```\n\nSometimes the inferred type is not the type you want the variable to have. For\nexample, you may intend to assign values of other types later. You may also\nwish to write a type annotation explicitly because the type of the initializing\nexpression is non-obvious and it will be helpful for future readers of the\ncode to document this type. Or you may wish to commit to a specific type such\nthat future updates of dependencies (in nearby code, in imports, anywhere)\nwill not silently change the type of that variable, thus introducing\ncompile-time errors or run-time bugs in locations where this variable is used.\nIn those cases, go ahead and annotate the variable with the type you want.\n\n**GOOD:**\n```dart\nWidget build(BuildContext context) {\n Widget result = someGenericFunction(42) ?? Text('You won!');\n if (applyPadding) {\n result = Padding(padding: EdgeInsets.all(8.0), child: result);\n }\n return result;\n}\n```\n\n**This rule is experimental.** It is being evaluated, and it may be changed\nor removed. Feedback on its behavior is welcome! The main issue is here:\nhttps://github.com/dart-lang/sdk/issues/58773.",
"sinceDartSdk": "3.6"
},
{
@@ -1723,7 +1723,7 @@
],
"sets": [],
"fixStatus": "hasFix",
- "details": "Don't type annotate initialized top-level or static variables when the type is\nobvious.\n\n**BAD:**\n```dart\nfinal int myTopLevelVariable = 7;\n\nclass A {\n static String myStaticVariable = 'Hello';\n}\n```\n\n**GOOD:**\n```dart\nfinal myTopLevelVariable = 7;\n\nclass A {\n static myStaticVariable = 'Hello';\n}\n```\n\nSometimes the inferred type is not the type you want the variable to have. For\nexample, you may intend to assign values of other types later. You may also\nwish to write a type annotation explicitly because the type of the initializing\nexpression is non-obvious and it will be helpful for future readers of the\ncode to document this type. Or you may wish to commit to a specific type such\nthat future updates of dependencies (in nearby code, in imports, anywhere)\nwill not silently change the type of that variable, thus introducing\ncompile-time errors or run-time bugs in locations where this variable is used.\nIn those cases, go ahead and annotate the variable with the type you want.\n\n**GOOD:**\n```dart\nfinal num myTopLevelVariable = 7;\n\nclass A {\n static String? myStaticVariable = 'Hello';\n}\n```\n\n**This rule is experimental.** It is being evaluated, and it may be changed\nor removed. Feedback on its behavior is welcome! The main issue is here:\nhttps://github.com/dart-lang/linter/issues/5101.",
+ "details": "Don't type annotate initialized top-level or static variables when the type is\nobvious.\n\n**BAD:**\n```dart\nfinal int myTopLevelVariable = 7;\n\nclass A {\n static String myStaticVariable = 'Hello';\n}\n```\n\n**GOOD:**\n```dart\nfinal myTopLevelVariable = 7;\n\nclass A {\n static myStaticVariable = 'Hello';\n}\n```\n\nSometimes the inferred type is not the type you want the variable to have. For\nexample, you may intend to assign values of other types later. You may also\nwish to write a type annotation explicitly because the type of the initializing\nexpression is non-obvious and it will be helpful for future readers of the\ncode to document this type. Or you may wish to commit to a specific type such\nthat future updates of dependencies (in nearby code, in imports, anywhere)\nwill not silently change the type of that variable, thus introducing\ncompile-time errors or run-time bugs in locations where this variable is used.\nIn those cases, go ahead and annotate the variable with the type you want.\n\n**GOOD:**\n```dart\nfinal num myTopLevelVariable = 7;\n\nclass A {\n static String? myStaticVariable = 'Hello';\n}\n```\n\n**This rule is experimental.** It is being evaluated, and it may be changed\nor removed. Feedback on its behavior is welcome! The main issue is here:\nhttps://github.com/dart-lang/sdk/issues/59550.",
"sinceDartSdk": "3.7"
},
{
@@ -2640,7 +2640,7 @@
],
"sets": [],
"fixStatus": "hasFix",
- "details": "Do type annotate initialized local variables when the type is non-obvious.\n\nType annotations on local variables can serve as a request for type inference,\ndocumenting the expected outcome of the type inference step, and declaratively\nallowing the compiler and analyzer to solve the possibly complex task of\nfinding type arguments and annotations in the initializing expression that\nyield the desired result.\n\nType annotations on local variables can also inform readers about the type\nof the initializing expression, which will allow them to proceed reading the\nsubsequent lines of code with known good information about the type of the\ngiven variable (which may not be immediately evident by looking at the\ninitializing expression).\n\nAn expression is considered to have a non-obvious type when it does not\nhave an obvious type.\n\nAn expression e has an obvious type in the following cases:\n\n- e is a non-collection literal. For instance, 1, true, 'Hello, $name!'.\n- e is a collection literal with actual type arguments. For instance,\n {}.\n- e is a list literal or a set literal where at least one element has an\n obvious type, and all elements have the same type. For instance, [1, 2] and\n { [true, false], [] }, but not [1, 1.5].\n- e is a map literal where all key-value pair have a key with an obvious type\n and a value with an obvious type, and all keys have the same type, and all\n values have the same type. For instance, { #a: [] }, but not\n {1: 1, 2: true}.\n- e is an instance creation expression whose class part is not raw. For\n instance C(14) if C is a non-generic class, or C(14) if C accepts one\n type argument, but not C(14) if C accepts one or more type arguments.\n- e is a cascade whose target has an obvious type. For instance,\n 1..isEven..isEven has an obvious type because 1 has an obvious type.\n- e is a type cast. For instance, myComplexExpression as int.\n\n**BAD:**\n```dart\nList> possibleDesserts(Set pantry) {\n var desserts = genericFunctionDeclaredFarAway([42], 'Something');\n for (final recipe in cookbook) {\n if (pantry.containsAll(recipe)) {\n desserts.add(recipe);\n }\n }\n\n return desserts;\n}\n\nconst List> cookbook = ...;\n```\n\n**GOOD:**\n```dart\nList> possibleDesserts(Set pantry) {\n List> desserts = genericFunctionDeclaredFarAway(\n [42],\n 'Something',\n );\n for (final List recipe in cookbook) {\n if (pantry.containsAll(recipe)) {\n desserts.add(recipe);\n }\n }\n\n return desserts;\n}\n\nconst List> cookbook = ...;\n```\n\n**This rule is experimental.** It is being evaluated, and it may be changed\nor removed. Feedback on its behavior is welcome! The main issue is here:\nhttps://github.com/dart-lang/linter/issues/3480.",
+ "details": "Do type annotate initialized local variables when the type is non-obvious.\n\nType annotations on local variables can serve as a request for type inference,\ndocumenting the expected outcome of the type inference step, and declaratively\nallowing the compiler and analyzer to solve the possibly complex task of\nfinding type arguments and annotations in the initializing expression that\nyield the desired result.\n\nType annotations on local variables can also inform readers about the type\nof the initializing expression, which will allow them to proceed reading the\nsubsequent lines of code with known good information about the type of the\ngiven variable (which may not be immediately evident by looking at the\ninitializing expression).\n\nAn expression is considered to have a non-obvious type when it does not\nhave an obvious type.\n\nAn expression e has an obvious type in the following cases:\n\n- e is a non-collection literal. For instance, 1, true, 'Hello, $name!'.\n- e is a collection literal with actual type arguments. For instance,\n {}.\n- e is a list literal or a set literal where at least one element has an\n obvious type, and all elements have the same type. For instance, [1, 2] and\n { [true, false], [] }, but not [1, 1.5].\n- e is a map literal where all key-value pair have a key with an obvious type\n and a value with an obvious type, and all keys have the same type, and all\n values have the same type. For instance, { #a: [] }, but not\n {1: 1, 2: true}.\n- e is an instance creation expression whose class part is not raw. For\n instance C(14) if C is a non-generic class, or C(14) if C accepts one\n type argument, but not C(14) if C accepts one or more type arguments.\n- e is a cascade whose target has an obvious type. For instance,\n 1..isEven..isEven has an obvious type because 1 has an obvious type.\n- e is a type cast. For instance, myComplexExpression as int.\n\n**BAD:**\n```dart\nList> possibleDesserts(Set pantry) {\n var desserts = genericFunctionDeclaredFarAway([42], 'Something');\n for (final recipe in cookbook) {\n if (pantry.containsAll(recipe)) {\n desserts.add(recipe);\n }\n }\n\n return desserts;\n}\n\nconst List> cookbook = ...;\n```\n\n**GOOD:**\n```dart\nList> possibleDesserts(Set pantry) {\n List> desserts = genericFunctionDeclaredFarAway(\n [42],\n 'Something',\n );\n for (final List recipe in cookbook) {\n if (pantry.containsAll(recipe)) {\n desserts.add(recipe);\n }\n }\n\n return desserts;\n}\n\nconst List> cookbook = ...;\n```\n\n**This rule is experimental.** It is being evaluated, and it may be changed\nor removed. Feedback on its behavior is welcome! The main issue is here:\nhttps://github.com/dart-lang/sdk/issues/58773.",
"sinceDartSdk": "3.6"
},
{
@@ -2653,7 +2653,7 @@
"incompatible": [],
"sets": [],
"fixStatus": "hasFix",
- "details": "Do type annotate initialized top-level or static variables when the type is\nnon-obvious.\n\nType annotations on top-level or static variables can serve as a request for\ntype inference, documenting the expected outcome of the type inference step,\nand declaratively allowing the compiler and analyzer to solve the possibly\ncomplex task of finding type arguments and annotations in the initializing\nexpression that yield the desired result.\n\nType annotations on top-level or static variables can also inform readers about\nthe type of the initializing expression, which will allow them to proceed\nreading the locations in code where this variable is used with known good\ninformation about the type of the given variable (which may not be immediately\nevident by looking at the initializing expression).\n\nAn expression is considered to have a non-obvious type when it does not\nhave an obvious type.\n\nAn expression e has an obvious type in the following cases:\n\n- e is a non-collection literal. For instance, 1, true, 'Hello, $name!'.\n- e is a collection literal with actual type arguments. For instance,\n {}.\n- e is a list literal or a set literal where at least one element has an\n obvious type, and all elements have the same type. For instance, [1, 2] and\n { [true, false], [] }, but not [1, 1.5].\n- e is a map literal where all key-value pair have a key with an obvious type\n and a value with an obvious type, and all keys have the same type, and all\n values have the same type. For instance, { #a: [] }, but not\n {1: 1, 2: true}.\n- e is an instance creation expression whose class part is not raw. For\n instance C(14) if C is a non-generic class, or C(14) if C accepts one\n type argument, but not C(14) if C accepts one or more type arguments.\n- e is a cascade whose target has an obvious type. For instance,\n 1..isEven..isEven has an obvious type because 1 has an obvious type.\n- e is a type cast. For instance, `myComplexExpression as int`.\n\n**BAD:**\n```dart\nfinal myTopLevelVariable =\n genericFunctionWrittenByOtherFolks(with, args);\n\nclass A {\n static var myStaticVariable =\n myTopLevelVariable.update('foo', null);\n}\n```\n\n**GOOD:**\n```dart\nfinal Map myTopLevelVariable =\n genericFunctionWrittenByOtherFolks(with, args);\n\nclass A {\n static Map myStaticVariable =\n myTopLevelVariable.update('foo', null);\n}\n```\n\n**This rule is experimental.** It is being evaluated, and it may be changed\nor removed. Feedback on its behavior is welcome! The main issue is here:\nhttps://github.com/dart-lang/linter/issues/5101.",
+ "details": "Do type annotate initialized top-level or static variables when the type is\nnon-obvious.\n\nType annotations on top-level or static variables can serve as a request for\ntype inference, documenting the expected outcome of the type inference step,\nand declaratively allowing the compiler and analyzer to solve the possibly\ncomplex task of finding type arguments and annotations in the initializing\nexpression that yield the desired result.\n\nType annotations on top-level or static variables can also inform readers about\nthe type of the initializing expression, which will allow them to proceed\nreading the locations in code where this variable is used with known good\ninformation about the type of the given variable (which may not be immediately\nevident by looking at the initializing expression).\n\nAn expression is considered to have a non-obvious type when it does not\nhave an obvious type.\n\nAn expression e has an obvious type in the following cases:\n\n- e is a non-collection literal. For instance, 1, true, 'Hello, $name!'.\n- e is a collection literal with actual type arguments. For instance,\n {}.\n- e is a list literal or a set literal where at least one element has an\n obvious type, and all elements have the same type. For instance, [1, 2] and\n { [true, false], [] }, but not [1, 1.5].\n- e is a map literal where all key-value pair have a key with an obvious type\n and a value with an obvious type, and all keys have the same type, and all\n values have the same type. For instance, { #a: [] }, but not\n {1: 1, 2: true}.\n- e is an instance creation expression whose class part is not raw. For\n instance C(14) if C is a non-generic class, or C(14) if C accepts one\n type argument, but not C(14) if C accepts one or more type arguments.\n- e is a cascade whose target has an obvious type. For instance,\n 1..isEven..isEven has an obvious type because 1 has an obvious type.\n- e is a type cast. For instance, `myComplexExpression as int`.\n\n**BAD:**\n```dart\nfinal myTopLevelVariable =\n genericFunctionWrittenByOtherFolks(with, args);\n\nclass A {\n static var myStaticVariable =\n myTopLevelVariable.update('foo', null);\n}\n```\n\n**GOOD:**\n```dart\nfinal Map myTopLevelVariable =\n genericFunctionWrittenByOtherFolks(with, args);\n\nclass A {\n static Map myStaticVariable =\n myTopLevelVariable.update('foo', null);\n}\n```\n\n**This rule is experimental.** It is being evaluated, and it may be changed\nor removed. Feedback on its behavior is welcome! The main issue is here:\nhttps://github.com/dart-lang/sdk/issues/59550.",
"sinceDartSdk": "3.7"
},
{
@@ -2794,7 +2794,7 @@
"flutter"
],
"fixStatus": "needsFix",
- "details": "**DON'T** use angle-bracketed text, `<…>`, in a doc comment unless you want to\nwrite an HTML tag or link.\n\nMarkdown allows HTML tags as part of the Markdown code, so you can write, for\nexample, `T1`. Markdown does not restrict the allowed tags, it just\nincludes the tags verbatim in the output.\n\nDartdoc only allows some known and valid HTML tags, and will omit any disallowed\nHTML tag from the output. See the list of allowed tags and directives below.\nYour doc comment should not contain any HTML tags that are not on this list.\n\nMarkdown also allows you to write an \"auto-link\" to an URL as for example\n``, delimited only by `<...>`. Such a link is\nallowed by Dartdoc as well.\nA `<...>` delimited text is an auto-link if it is a valid absolute URL, starting\nwith a scheme of at least two characters followed by a colon, like\n``.\n\nAny other other occurrence of `` or `` is likely a mistake\nand this lint will warn about it.\nIf something looks like an HTML tag, meaning it starts with `<` or ``, then it's considered an\ninvalid HTML tag unless it is an auto-link, or it starts with an *allowed*\nHTML tag.\n\nSuch a mistake can, for example, happen if writing Dart code with type arguments\noutside of a code span, for example `The type List is ...`, where ``\nlooks like an HTML tag. Missing the end quote of a code span can have the same\neffect: ``The type `List is ...`` will also treat `` as an HTML tag.\n\nAllows the following HTML directives: HTML comments, ``, processing\ninstructions, ``, CDATA-sections, and `<[CDATA...]>`.\nAllows DartDoc links like `[List]` which are not after a `]` or before a\n`[` or `(`, and allows the following recognized HTML tags:\n`a`, `abbr`, `address`, `area`, `article`, `aside`, `audio`, `b`,\n`bdi`, `bdo`, `blockquote`, `br`, `button`, `canvas`, `caption`,\n`cite`, `code`, `col`, `colgroup`, `data`, `datalist`, `dd`, `del`,\n`dfn`, `div`, `dl`, `dt`, `em`, `fieldset`, `figcaption`, `figure`,\n`footer`, `form`, `h1`, `h2`, `h3`, `h4`, `h5`, `h6`, `header`, `hr`,\n`i`, `iframe`, `img`, `input`, `ins`, `kbd`, `keygen`, `label`,\n`legend`, `li`, `link`, `main`, `map`, `mark`, `meta`, `meter`, `nav`,\n`noscript`, `object`, `ol`, `optgroup`, `option`, `output`, `p`,\n`param`, `pre`, `progress`, `q`, `s`, `samp`, `script`, `section`,\n`select`, `small`, `source`, `span`, `strong`, `style`, `sub`, `sup`,\n`table`, `tbody`, `td`, `template`, `textarea`, `tfoot`, `th`, `thead`,\n`time`, `title`, `tr`, `track`, `u`, `ul`, `var`, `video` and `wbr`.\n\n**BAD:**\n```dart\n/// The type List.\n/// -> = \n```\n\n**GOOD:**\n```dart\n/// The type `List`.\n/// The type [List]\n/// ` -> = `\n/// \\ -> \\ = \\`\n/// \n```",
+ "details": "**DON'T** use angle-bracketed text, `<…>`, in a doc comment unless you want to\nwrite an HTML tag or link.\n\nMarkdown allows HTML tags as part of the Markdown code, so you can write, for\nexample, `T1`. Markdown does not restrict the allowed tags, it just\nincludes the tags verbatim in the output.\n\nDartdoc only allows some known and valid HTML tags, and will omit any disallowed\nHTML tag from the output. See the list of allowed tags and directives below.\nYour doc comment should not contain any HTML tags that are not on this list.\n\nMarkdown also allows you to write an \"auto-link\" to an URL as for example\n``, delimited only by `<...>`. Such a link is\nallowed by Dartdoc as well.\nA `<...>` delimited text is an auto-link if it is a valid absolute URL, starting\nwith a scheme of at least two characters followed by a colon, like\n``.\n\nAny other other occurrence of `` or `` is likely a mistake\nand this lint will warn about it.\nIf something looks like an HTML tag, meaning it starts with `<` or ``, then it's considered an\ninvalid HTML tag unless it is an auto-link, or it starts with an *allowed*\nHTML tag.\n\nSuch a mistake can, for example, happen if writing Dart code with type arguments\noutside of a code span, for example `The type List is ...`, where ``\nlooks like an HTML tag. Missing the end quote of a code span can have the same\neffect: ``The type `List is ...`` will also treat `` as an HTML tag.\n\nAllows the following HTML directives: HTML comments, ``, processing\ninstructions, ``, CDATA-sections, and `<[CDATA...]>`.\nAllows DartDoc links like `[List]` which are not after a `]` or before a\n`[` or `(`, and allows the following recognized HTML tags:\n`a`, `abbr`, `address`, `area`, `article`, `aside`, `audio`, `b`,\n`bdi`, `bdo`, `blockquote`, `br`, `button`, `canvas`, `caption`,\n`cite`, `code`, `col`, `colgroup`, `data`, `datalist`, `dd`, `del`,\n`dfn`, `div`, `dl`, `dt`, `em`, `fieldset`, `figcaption`, `figure`,\n`footer`, `form`, `h1`, `h2`, `h3`, `h4`, `h5`, `h6`, `header`, `hr`,\n`i`, `iframe`, `img`, `input`, `ins`, `kbd`, `keygen`, `label`,\n`legend`, `li`, `link`, `main`, `map`, `mark`, `meta`, `meter`, `nav`,\n`noscript`, `object`, `ol`, `optgroup`, `option`, `output`, `p`,\n`param`, `pre`, `progress`, `q`, `s`, `samp`, `script`, `section`,\n`select`, `small`, `source`, `span`, `strong`, `style`, `sub`, `sup`,\n`table`, `tbody`, `td`, `template`, `textarea`, `tfoot`, `th`, `thead`,\n`time`, `title`, `tr`, `track`, `u`, `ul`, `var`, `video` and `wbr`.\n\n**BAD:**\n```dart\n/// The type List.\n/// -> = \n```\n\n**GOOD:**\n```dart\n/// The type `List`.\n/// The type [List]\n/// ` -> = `\n/// \\ -> \\ = \\`\n/// \n```",
"sinceDartSdk": "3.5"
},
{
@@ -2851,7 +2851,7 @@
"incompatible": [],
"sets": [],
"fixStatus": "hasFix",
- "details": "Only use a `break` in a non-empty switch case statement if you need to break\nbefore the end of the case body. Dart does not support fallthrough execution\nfor non-empty cases, so `break`s at the end of non-empty switch case statements\nare unnecessary.\n\n**BAD:**\n```dart\nswitch (1) {\n case 1:\n print(\"one\");\n break;\n case 2:\n print(\"two\");\n break;\n}\n```\n\n**GOOD:**\n```dart\nswitch (1) {\n case 1:\n print(\"one\");\n case 2:\n print(\"two\");\n}\n```\n\n```dart\nswitch (1) {\n case 1:\n case 2:\n print(\"one or two\");\n}\n```\n\n```dart\nswitch (1) {\n case 1:\n break;\n case 2:\n print(\"just two\");\n}\n```\n\nNOTE: This lint only reports unnecessary breaks in libraries with a\n[language version](https://dart.dev/guides/language/evolution#language-versioning)\nof 3.0 or greater. Explicit breaks are still required in Dart 2.19 and below.",
+ "details": "Only use a `break` in a non-empty switch case statement if you need to break\nbefore the end of the case body. Dart does not support fallthrough execution\nfor non-empty cases, so `break`s at the end of non-empty switch case statements\nare unnecessary.\n\n**BAD:**\n```dart\nswitch (1) {\n case 1:\n print(\"one\");\n break;\n case 2:\n print(\"two\");\n break;\n}\n```\n\n**GOOD:**\n```dart\nswitch (1) {\n case 1:\n print(\"one\");\n case 2:\n print(\"two\");\n}\n```\n\n```dart\nswitch (1) {\n case 1:\n case 2:\n print(\"one or two\");\n}\n```\n\n```dart\nswitch (1) {\n case 1:\n break;\n case 2:\n print(\"just two\");\n}\n```\n\nNOTE: This lint only reports unnecessary breaks in libraries with a\n[language version](https://dart.dev/resources/language/evolution#language-versioning)\nof 3.0 or greater. Explicit breaks are still required in Dart 2.19 and below.",
"sinceDartSdk": "3.0"
},
{
@@ -3227,7 +3227,10 @@
],
"state": "stable",
"incompatible": [],
- "sets": [],
+ "sets": [
+ "recommended",
+ "flutter"
+ ],
"fixStatus": "hasFix",
"details": "**AVOID** using multiple underscores when a single wildcard will do.\n\n**BAD:**\n```dart\nvoid function(int __) { }\n```\n\n**GOOD:**\n```dart\nvoid function(int _) { }\n```",
"sinceDartSdk": "3.7"
diff --git a/src/_data/site.yml b/src/_data/site.yml
index 0ec69ead74..45a003d38f 100644
--- a/src/_data/site.yml
+++ b/src/_data/site.yml
@@ -40,4 +40,4 @@ showBanner: true
# in the `firebase.json` redirect rule.)
og_image_vers: "?2"
-sdkVersion: 3.7.0
+sdkVersion: 3.7.1
diff --git a/src/content/language/built-in-types.md b/src/content/language/built-in-types.md
index 84dbefaf86..05a46d3465 100644
--- a/src/content/language/built-in-types.md
+++ b/src/content/language/built-in-types.md
@@ -189,7 +189,7 @@ var n5 = 100__000_000__000_000; // one hundred million million!
```
:::version-note
-Using digit separators requires a [language version][] of at least 3.6.0.
+Using digit separators requires a [language version][] of at least 3.6.
:::
## Strings
diff --git a/src/content/tools/diagnostic-messages.md b/src/content/tools/diagnostic-messages.md
index 85fa2b3cf7..7ebd0fd849 100644
--- a/src/content/tools/diagnostic-messages.md
+++ b/src/content/tools/diagnostic-messages.md
@@ -1282,7 +1282,7 @@ function producing the value.
### assignment_to_const
-_Constant variables can't be assigned a value._
+_Constant variables can't be assigned a value after initialization._
#### Description
@@ -6154,7 +6154,7 @@ Remove the constructor or replace it with a static method.
### extension_declares_instance_field
-_Extensions can't declare instance fields_
+_Extensions can't declare instance fields._
#### Description
@@ -6175,8 +6175,37 @@ extension E on String {
#### Common fixes
-Remove the field, make it a static field, or convert it to be a getter,
-setter, or method.
+If the value can be computed without storing it in a field,
+then try using a getter or a method:
+
+```dart
+extension E on String {
+ String get s => '';
+
+ void s(String value) => print(s);
+}
+```
+
+If the value must be stored, but is the same for every instance,
+try using a static field:
+
+```dart
+extension E on String {
+ static String s = '';
+}
+```
+
+If each instance needs to have its own value stored,
+then try using a getter and setter pair backed by a static `Expando`:
+
+```dart
+extension E on SomeType {
+ static final _s = Expando();
+
+ String get s => _s[this] ?? '';
+ set s(String value) => _s[this] = value;
+}
+```
### extension_declares_member_of_object
@@ -28701,12 +28730,13 @@ ignored._
#### Description
-The analyzer produces this diagnostic when an ignore is specified to ignore a diagnostic that isn't produced.
+The analyzer produces this diagnostic when an ignore is specified to
+ignore a diagnostic that isn't produced.
#### Example
-The following code produces this diagnostic because the `unused_local_variable`
-diagnostic isn't reported at the ignored location:
+The following code produces this diagnostic because the
+`unused_local_variable` diagnostic isn't reported at the ignored location:
```dart
// ignore: [!unused_local_variable!]
@@ -29756,6 +29786,33 @@ variable:
Duration d = Duration.zero;
```
+### use_null_aware_elements
+
+_Use the null-aware marker '?' rather than a null check via an 'if'._
+
+#### Description
+
+The analyzer produces this diagnostic when a null check is used instead
+of a null-aware marker inside of a collection literal.
+
+#### Example
+
+The following code produces this diagnostic because a null check is used
+to decide whether `x` should be inserted into the list, while the
+null-aware marker '?' would be less brittle and less verbose.
+
+```dart
+f(int? x) => [[!if!] (x != null) x];
+```
+
+#### Common fixes
+
+Replace the null-check with the null-aware marker '?':
+
+```dart
+f(int? x) => [?x];
+```
+
### use_raw_strings
_Use a raw string to avoid using escapes._
From 5d837cd5bac65d7c0c64acdcc9c0684cd0d2ca87 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Mon, 3 Mar 2025 11:28:19 -0600
Subject: [PATCH 5/5] Bump @types/node from 22.13.5 to 22.13.8 (#6469)
Bumps
[@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node)
from 22.13.5 to 22.13.8.
Commits
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
Signed-off-by: dependabot[bot]
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
---
package.json | 2 +-
pnpm-lock.yaml | 14 +++++++-------
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/package.json b/package.json
index 512ea0bce1..f40eecb2f3 100644
--- a/package.json
+++ b/package.json
@@ -22,7 +22,7 @@
"@11ty/eleventy": "^3.0.0",
"@types/hast": "^3.0.4",
"@types/markdown-it": "^14.1.2",
- "@types/node": "^22.13.5",
+ "@types/node": "^22.13.8",
"firebase-tools": "^13.32.0",
"hast-util-from-html": "^2.0.3",
"hast-util-select": "^6.0.4",
diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml
index 31848787f2..36c13654e1 100644
--- a/pnpm-lock.yaml
+++ b/pnpm-lock.yaml
@@ -18,8 +18,8 @@ importers:
specifier: ^14.1.2
version: 14.1.2
'@types/node':
- specifier: ^22.13.5
- version: 22.13.5
+ specifier: ^22.13.8
+ version: 22.13.8
firebase-tools:
specifier: ^13.32.0
version: 13.32.0(encoding@0.1.13)
@@ -559,8 +559,8 @@ packages:
'@types/mdurl@2.0.0':
resolution: {integrity: sha512-RGdgjQUZba5p6QEFAVx2OGb8rQDL/cPRG7GiedRzMcJ1tYnUANBncjbSB1NRGwbvjcPeikRABz2nshyPk1bhWg==}
- '@types/node@22.13.5':
- resolution: {integrity: sha512-+lTU0PxZXn0Dr1NBtC7Y8cR21AJr87dLLU953CWA6pMxxv/UDc7jYAY90upcrie1nRcD6XNG5HOYEDtgW5TxAg==}
+ '@types/node@22.13.8':
+ resolution: {integrity: sha512-G3EfaZS+iOGYWLLRCEAXdWK9my08oHNZ+FHluRiggIYJPOXzhOiDgpVCUHaUvyIC5/fj7C/p637jdzC666AOKQ==}
'@types/request@2.48.12':
resolution: {integrity: sha512-G3sY+NpsA9jnwm0ixhAFQSJ3Q9JkpLZpJbI3GMv0mIAT0y3mRabYeINzal5WOChIiaTEGQYlHOKgkaM9EisWHw==}
@@ -3690,14 +3690,14 @@ snapshots:
'@types/mdurl@2.0.0': {}
- '@types/node@22.13.5':
+ '@types/node@22.13.8':
dependencies:
undici-types: 6.20.0
'@types/request@2.48.12':
dependencies:
'@types/caseless': 0.12.5
- '@types/node': 22.13.5
+ '@types/node': 22.13.8
'@types/tough-cookie': 4.0.5
form-data: 2.5.3
@@ -5887,7 +5887,7 @@ snapshots:
'@protobufjs/path': 1.1.2
'@protobufjs/pool': 1.1.0
'@protobufjs/utf8': 1.1.0
- '@types/node': 22.13.5
+ '@types/node': 22.13.8
long: 5.3.1
proxy-addr@2.0.7: