feat: Use new enhanced enums for ExitCode

[eseidel]

I wrote this patch hoping to make ExitCode.success.code usable from within a const expression. But it turns out that it's still not usable within const. However the code is now cleaner after the change, so still offering the patch.

I don't think this should break callers in the wild, but feel free to reject the change if you're worried about such.

[natebosch]

I think it should be fine to roll out this change even without a major version bump because I do expect it to be non-breaking in practice for all users of this package. @lrhn do you have any concerns?

[github-actions]

Package publishing

Package	Version	Status	Publish tag (post-merge)
package:bazel_worker	1.1.3	already published at pub.dev
package:benchmark_harness	2.3.1	already published at pub.dev
package:boolean_selector	2.1.2	already published at pub.dev
package:browser_launcher	1.1.3	already published at pub.dev
package:cli_config	0.2.1-wip	WIP (no publish necessary)
package:cli_util	0.4.2	already published at pub.dev
package:clock	1.1.2	already published at pub.dev
package:code_builder	4.10.2-wip	WIP (no publish necessary)
package:coverage	1.12.0	already published at pub.dev
package:csslib	1.0.2	already published at pub.dev
package:extension_discovery	2.1.0	already published at pub.dev
package:file	7.0.2-wip	WIP (no publish necessary)
package:file_testing	3.1.0-wip	WIP (no publish necessary)
package:glob	2.1.3	already published at pub.dev
package:graphs	2.3.3-wip	WIP (no publish necessary)
package:html	0.15.6-wip	WIP (no publish necessary)
package:io	1.1.0-wip	WIP (no publish necessary)
package:json_rpc_2	4.0.0	ready to publish	json_rpc_2-v4.0.0
package:markdown	7.3.1-wip	WIP (no publish necessary)
package:mime	2.0.0	already published at pub.dev
package:oauth2	2.0.4-wip	WIP (no publish necessary)
package:package_config	2.3.0-wip	WIP (no publish necessary)
package:pool	1.5.2-wip	WIP (no publish necessary)
package:pub_semver	2.2.0	already published at pub.dev
package:pubspec_parse	1.5.0	already published at pub.dev
package:source_map_stack_trace	2.1.3-wip	WIP (no publish necessary)
package:source_maps	0.10.14-wip	WIP (no publish necessary)
package:source_span	1.10.1	already published at pub.dev
package:sse	4.1.8	ready to publish	sse-v4.1.8
package:stack_trace	1.12.1	already published at pub.dev
package:stream_channel	2.1.4	already published at pub.dev
package:stream_transform	2.1.2-wip	WIP (no publish necessary)
package:string_scanner	1.4.1	already published at pub.dev
package:term_glyph	1.2.3-wip	WIP (no publish necessary)
package:test_reflective_loader	0.2.3	already published at pub.dev
package:timing	1.0.2	already published at pub.dev
package:unified_analytics	8.0.1	already published at pub.dev
package:watcher	1.1.1	already published at pub.dev
package:yaml	3.1.3	already published at pub.dev
package:yaml_edit	2.2.2	already published at pub.dev

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

[github-actions]

PR Health

Breaking changes ✔️

Package	Change	Current Version	New Version	Needed Version	Looking good?
io	Non-Breaking	1.0.5	1.1.0-wip	1.1.0	✔️

Changelog Entry ✔️

Package	Changed Files

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

Coverage ✔️

File	Coverage
pkgs/io/lib/src/exit_code.dart	💚 100 % ⬆️ 200 %

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

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) 2025, 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.

Unrelated files missing license headers

Files
pkgs/bazel_worker/benchmark/benchmark.dart
pkgs/bazel_worker/example/client.dart
pkgs/bazel_worker/example/worker.dart
pkgs/benchmark_harness/integration_test/perf_benchmark_test.dart
pkgs/boolean_selector/example/example.dart
pkgs/clock/lib/clock.dart
pkgs/clock/lib/src/clock.dart
pkgs/clock/lib/src/default.dart
pkgs/clock/lib/src/stopwatch.dart
pkgs/clock/lib/src/utils.dart
pkgs/clock/test/clock_test.dart
pkgs/clock/test/default_test.dart
pkgs/clock/test/stopwatch_test.dart
pkgs/clock/test/utils.dart
pkgs/coverage/lib/src/coverage_options.dart
pkgs/coverage/test/collect_coverage_config_test.dart
pkgs/coverage/test/config_file_locator_test.dart
pkgs/html/example/main.dart
pkgs/html/lib/dom.dart
pkgs/html/lib/dom_parsing.dart
pkgs/html/lib/html_escape.dart
pkgs/html/lib/parser.dart
pkgs/html/lib/src/constants.dart
pkgs/html/lib/src/encoding_parser.dart
pkgs/html/lib/src/html_input_stream.dart
pkgs/html/lib/src/list_proxy.dart
pkgs/html/lib/src/query_selector.dart
pkgs/html/lib/src/token.dart
pkgs/html/lib/src/tokenizer.dart
pkgs/html/lib/src/treebuilder.dart
pkgs/html/lib/src/utils.dart
pkgs/html/test/dom_test.dart
pkgs/html/test/parser_feature_test.dart
pkgs/html/test/parser_test.dart
pkgs/html/test/query_selector_test.dart
pkgs/html/test/selectors/level1_baseline_test.dart
pkgs/html/test/selectors/level1_lib.dart
pkgs/html/test/selectors/selectors.dart
pkgs/html/test/support.dart
pkgs/html/test/tokenizer_test.dart
pkgs/pubspec_parse/test/git_uri_test.dart
pkgs/stack_trace/example/example.dart
pkgs/watcher/test/custom_watcher_factory_test.dart
pkgs/yaml_edit/example/example.dart

[lrhn]

Do we expect users to start switching over exit codes? If so, it becomes breaking to add another exit code in the future.

Or could anyone already be switching inexhaustible on them. Then this is breaking.

(Would be nice to have a shorter syntax for breaking static constants without inducing exhaustion.)

[eseidel]

I’m really not attached to this at all, please feel free to discard. My original purpose was I wanted ‘ExitCode.success.code’ usable within a const expression, but it turns out that’s some other dart language limitation. If this has any reasonable chance of breaking, I doubt it’s worth the hassle. 🤷🏼‍♂️

…

On Tue, Apr 22, 2025 at 11:43 PM Lasse R.H. Nielsen < ***@***.***> wrote: Do we expect users to start switching over exit codes? If so, it becomes breaking to add another exit code in the future. Or could anyone already be switching inexhaustible on them. Then this is breaking. (Would be nice to have a shorter syntax for breaking static constants without inducing exhaustion.) — Reply to this email directly, view it on GitHub <#2078 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADU2TONFZTJ7QJWLL3RCOT224Y7RAVCNFSM6AAAAAB3UZPWL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMRTGIZTAMRTGY> . You are receiving this because you authored the thread.Message ID: ***@***.***> *lrhn* left a comment (dart-lang/tools#2078) <#2078 (comment)> Do we expect users to start switching over exit codes? If so, it becomes breaking to add another exit code in the future. Or could anyone already be switching inexhaustible on them. Then this is breaking. (Would be nice to have a shorter syntax for breaking static constants without inducing exhaustion.) — Reply to this email directly, view it on GitHub <#2078 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADU2TONFZTJ7QJWLL3RCOT224Y7RAVCNFSM6AAAAAB3UZPWL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMRTGIZTAMRTGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>