[ffigen] fix missing exports used in the FfiGenerator

[josxha]

This pr exports a missing class and some enums used by the FfiGenerator.

• fix [Interop EAP] Missing exports used in FfiGenerator (ffigen v20.0.0) #2765
• export the enums CommentLength, CommentStyle and EnumStyle
• export the class Version

Caution: The class Version comes from the pub_semver package. In general I'd say exporting an external class introduces some risk in case the package does not follow semantic versioning. In this case however it is a tools.dart.dev package, so in my opinion the risk is neglectable.

---

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

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

Note: The Dart team is trialing Gemini Code Assist. Don't take its comments as final Dart team feedback. Use the suggestions if they're helpful; otherwise, wait for a human reviewer.

[github-actions]

PR Health

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/objective_c/lib/src/ns_input_stream.dart

This check can be disabled by tagging the PR with skip-license-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 symbol	Leaking sources

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

Breaking changes ✔️

Package	Change	Current Version	New Version	Needed Version	Looking good?

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

Changelog Entry ✔️

Package	Changed Files

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

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

[dcharkes]

Thanks @josxha! 🙏

• export the class Version

It's unlikely that users would already depend on and import package pub_semver, so this is okay to me.

Maybe it would be even better to just make a Version in this package. Unless we reuse a lot of the implementation. @liamappelbe any opinion about this?

Caution: The class Version comes from the pub_semver package. In general I'd say exporting an external class introduces some risk in case the package does not follow semantic versioning. In this case however it is a tools.dart.dev package, so in my opinion the risk is neglectable.

I'm assuming that package uses correct semantic versioning (pun intended), so we'd have to bump the major version on breaking changes. And when we do, our dart_apitool integration should flag it as a required breaking change.

[coveralls]

coverage: 81.971%. remained the same
when pulling d6a7711 on josxha:fix-missing-package-exports
into 0e7789d on dart-lang:main.

[liamappelbe]

Thanks, but I already have a CL out that fixes this: #2768

It's unlikely that users would already depend on and import package pub_semver, so this is okay to me.

Why would it be an issue if they did import pub_semver?

Maybe it would be even better to just make a Version in this package. Unless we reuse a lot of the implementation. @liamappelbe any opinion about this?

The only logic we need is parsing strings to versions, and comparing two versions. It wouldn't be hard to write our own Version if that's something we need. But all else being equal, I'd rather reuse the existing implementation.

[dcharkes]

Why would it be an issue if they did import pub_semver?

Usability: non unique imports. It would be ambiguous which of the two packages to import. And then if you first import package pub_semver, and then later FFIgen, then the pub semver import is not needed because all imports are already in package FFIgen. However, I don't believe this to be a likely scenario. So, it's okay to me to export pub semver's version.

[josxha]

Thanks for the feedback. I'm closing this pr as it gets superseeded by Liams' in #2768.

Usability: non unique imports. It would be ambiguous which of the two packages to import. And then if you first import package pub_semver, and then later FFIgen, then the pub semver import is not needed because all imports are already in package FFIgen. However, I don't believe this to be a likely scenario. So, it's okay to me to export pub semver's version.

I think the lints will point in the right direction. Seee for example the failed ci in this pr where it flagged pub_semver/pub_semver.dart, not ffigen/ffigen.dart:

info • The import of 'package:pub_semver/pub_semver.dart' is unnecessary because all of the used elements are also 
provided by the import of 'package:ffigen/ffigen.dart' • test/large_integration_tests/large_objc_test.dart:19:8 • unnecessary_import