Repository navigation
[web, tool] Look into public packages blocking wasm builds and reporting them in analytics #178894
Description
There are three classes of package:
-ha- the "host application". Do NOT include the actual app package name.-pp- a "private package", i.e. non-public and/or non-published package. Do NOT include the actual name of any non-public package.[pkg name]:X.Y.Z- the name of a public, published package with the version (with truncated zeros, see below)
The hyphen is critical. Since hyphens are not allowed in package names, we make sure we don't have collisions.
To determine if a package can be reported in analytics, look at pubspec.lock
A package is considered public and loggable if an only if:
source: hosteddescription -> url: "https://pub.dev"
Here's an example entry from a pubspec.lock file.
args:
dependency: transitive
description:
name: args
sha256: d0481093c50b1da8910eb0bb301626d4d8eb7284aa739614d2b394ee09e3ea04
url: "https://pub.dev"
source: hosted
version: "2.7.0"Any analytics reporting should include the package name and version. Because we are limited to 100 characters, we want this to be short. So the predefined values are 3 characters long. There should be no spaces. There should be no duplicate entries. The version should be truncated if the last value is 0. So pkg1 at v1.0.0 should be logged as pkg1:1 and pkg2 at v2.3.0 should be logged as pkg2:2.3.
A sample report could look like:
-ha,-pp,pkg1:1.2.5,pkg2:1,pkg3:1.2
- Update
pkg:unified_analyticsAdd wasm_dry_run_package event to track public package names from wasm dry run findings. dart-lang/tools#2279
Activity
[-][web, tool] Look into public packages blocking web builds and reporting them in analytics[/-][+][web, tool] Look into public packages blocking wasm builds and reporting them in analytics[/+]Add package info to wasm dry run events. (#179826)
kevmoo commentedon Jan 5, 2026
We have data all the way through. Now pondering if we can "roll up" usage of
package:jsone level to report packages USING it.srujzs commentedon Jan 20, 2026
I believe there are two things we want here looking at our dry run reporting in dart2wasm:
package:jsimports in user code.dart:js_utilimports in user code (which is also available through inpackage:js).The current JS interop checks do not check for imports beyond
dart:ffiin dart2wasm only (maybe at some point this included more like invalid JS interop libraries, but not anymore). We have explicit checks fordart:jsanddart:htmland have associated dry run codes for those, so we'll have to do the same for these two imports.srujzs commentedon Jan 20, 2026
Yeah, I think when we fully removed
package:jsanddart:js_utilsupport from dart2wasm, we removed these from the interop checks because the CFE would already report the errors. This had the side-effect of affecting this dry-run. It's better anyways that we explicitly check for those imports in the dry run instead of relying on the JS interop checks.srujzs commentedon Jan 20, 2026
I can add the extra errors for the two imports and it doesn't look like Flutter needs to be updated after that as it just pipes the error code directly through.
[dart2wasm] Add more interop libraries to dry-run
kevmoo commentedon Jan 27, 2026
Closing this out. I think we're good with the last commit.
[beta][dart2wasm] Add more interop libraries to dry-run
github-actions commentedon Feb 10, 2026
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.