Value read from the compile-time environment declaration
ID |
dart.portability.do_not_use_environment |
Severity |
info |
Remediation Complexity |
medium |
Remediation Risk |
medium |
Remediation Effort |
medium |
Resource |
Portability |
Language |
Dart |
Description
Reports a use of the environment-declaration constructors String.fromEnvironment, int.fromEnvironment, bool.fromEnvironment and bool.hasEnvironment, which read values passed to the compiler with -D / --define.
Rationale
These values are baked in at compile time by whoever ran the build, so the same source produces different programs depending on the environment declarations of the machine that compiled it. That makes behaviour hard to reproduce, and the failure mode is silent: a declaration that is simply absent yields the default value (empty string, 0, false) rather than an error, so a typo in a build script turns into a feature that quietly does not work. The values also vary by platform - the web compilers and the VM do not accept the same set - which makes code that branches on them behave differently per target.
The following code illustrates the pattern detected by this rule:
class Config {
// FLAGGED: Value read from the compile-time environment declaration
static const flavor = String.fromEnvironment('FLAVOR');
}Remediation
Take the value from an explicit, inspectable source instead: a generated configuration class, an asset or a --dart-define-from-file JSON checked into the build, or a runtime lookup (Platform.environment) where a runtime value is what is really wanted. If a compile-time constant is genuinely required, keep the set of declarations in one place, give every one a defaultValue, and assert the value is one you expect at start-up.