Expose the app's build name and number as compile-time constants#187935
Open
Ortes wants to merge 2 commits into
Open
Expose the app's build name and number as compile-time constants#187935Ortes wants to merge 2 commits into
Ortes wants to merge 2 commits into
Conversation
The tool already injects FLUTTER_VERSION, FLUTTER_CHANNEL, framework and engine revisions (FlutterVersion) and FLUTTER_APP_FLAVOR (appFlavor) as dart-defines. The application's own version from pubspec.yaml is the one missing field, even though the tool already parses it (FlutterManifest.buildName/buildNumber) and embeds it into version.json, Info.plist and build.gradle. Without it, the running version is unknowable on the web: version.json is fetched from the server at runtime, so a stale cached client reports the freshly deployed version instead of its own. Version gates and update prompts built on package_info_plus silently fail for exactly the users they exist for. This injects FLUTTER_BUILD_NAME and FLUTTER_BUILD_NUMBER (from the --build-name/--build-number flags, falling back to the pubspec version) following the FLUTTER_APP_FLAVOR pattern, and exposes them as appBuildName/appBuildNumber constants in package:flutter/services.dart. Like all String.fromEnvironment constants they are tree-shaken when unreferenced, so nothing ships unless the app reads them.
Contributor
There was a problem hiding this comment.
Code Review
This pull request introduces 'appBuildName' and 'appBuildNumber' constants to the services library, allowing applications to access their build name and build number at runtime. These values are injected into 'dartDefines' during the build process, with validation to prevent users from manually overriding them. Feedback suggests refining the validation logic when checking existing 'dartDefines' to avoid false positives on custom variables that share a prefix with the framework-defined build variables.
Ortes
added a commit
to Fullphysio/plus_plugins
that referenced
this pull request
Jun 12, 2026
…allbacks PackageInfoEnvironment now resolves the web version from, in order: PACKAGE_INFO_PLUS_VERSION (explicit), FLUTTER_BUILD_NAME (flutter/flutter#187935, injected by flutter_tools like FLUTTER_APP_FLAVOR), and dart.package.version (dart-lang/sdk#38855). Once either upstream proposal lands, apps need no configuration at all.
Ortes
added a commit
to Fullphysio/plus_plugins
that referenced
this pull request
Jun 12, 2026
…allbacks PackageInfoEnvironment now resolves the web version from, in order: PACKAGE_INFO_PLUS_VERSION (explicit), FLUTTER_BUILD_NAME (flutter/flutter#187935, injected by flutter_tools like FLUTTER_APP_FLAVOR), and dart.package.version (dart-lang/sdk#38855). Once either upstream proposal lands, apps need no configuration at all.
This was referenced Jun 12, 2026
User-provided defines that merely share a prefix with a reserved key (e.g. FLUTTER_BUILD_NAMESPACE vs FLUTTER_BUILD_NAME) no longer trip the reserved-key validation. Also fixes the same pre-existing prefix match on FLUTTER_APP_FLAVOR.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The tool already injects
FLUTTER_VERSION,FLUTTER_CHANNEL, framework/engine revisions (exposed asFlutterVersion) andFLUTTER_APP_FLAVOR(exposed asappFlavor) as dart-defines. The application's ownversion:frompubspec.yamlis the one missing field, even though the tool already parses it (FlutterManifest.buildName/buildNumber) and embeds it intoversion.json,Info.plistandbuild.gradleon every build.Without it, the running version is unknowable on the web:
version.jsonis fetched from the server at runtime, so a stale cached client reports the freshly deployed version instead of its own, and version gates / update prompts built onpackage_info_plussilently fail for exactly the users they exist for (fluttercommunity/plus_plugins#2675).This PR:
FLUTTER_BUILD_NAMEandFLUTTER_BUILD_NUMBER(from--build-name/--build-number, falling back to the pubspecversion) inFlutterCommand.getBuildInfo, following theFLUTTER_APP_FLAVORpattern including its reserved-name guards;appBuildName/appBuildNumberconstants inpackage:flutter/services.dart(newsrc/services/app_version.dart, same style asflavor.dart/flutter_version.dart);Like all
String.fromEnvironmentconstants, these are tree-shaken when unreferenced, so nothing ships in the binary unless the app reads them.package_info_plusis ready to consume these defines (fluttercommunity/plus_plugins#3874), which would make the fix transparent for the ecosystem. A companion proposal for the pure-Dart side (dart compile, servers/CLIs) is dart-lang/sdk#38855 — neither subsumes the other, since Flutter does not build throughdartdev.Fixes #187934
Pre-launch Checklist
///).