In the case of a multi-app scenario, different applications may store
files in different locations. In order to avoid reloading files that
were unchanged, a suffix can be added to indicate which "version" of
this file we're loading. Even if it has a different path, because the id
and "version" (which is URL(...).search) are the same, the file would
not be reloaded.
With Flutter tools, this scenario doesn't occur. The running application
ultimately does not need to worry about the same file in different
locations.
The benefit to avoid this caching is that the user only ever sees one
copy of every file, which is the latest version, instead of the current
behavior where a "gen=N" suffix is added to a newer version.
Note that this is unrelated to the XHR or its headers or any of its
caching mechanisms. The XHR is only used to fetch the *list* of changed
files, not the files themselves. The files get loaded as part of the
`appendChild` call.
https://github.com/flutter/flutter/issues/166294
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [ ] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
The path to reload scripts JSON was being added to the global window
before. It should instead be passed to the provider on setup. In order
to do this, the baseUri calculation is moved into the WebAssetServer.
This is safe because Flutter tools was calculating it immediately
after creating the server anyways.
https://github.com/dart-lang/webdev/issues/2584
Existing hot reload tests should test this behavior.
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [ ] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [ ] All existing and new tests are passing.
The existing code assumed that DWDS needed to initialize some of the JS
state between adding all the scripts to queue and when they are loaded.
A closer examination of the existing AMD module format bootstrapper
shows that we already only initialize DWDS' JS state after all the
scripts are loaded. This is because it waits for the entrypoint to be
loaded before initializing that state, and the entrypoint is only loaded
after all its dependencies are loaded, which includes the SDK and
transitively every file in the app.
Since it's simpler and avoids the double-gating to call main, this
change moves that initialization to after all the scripts are loaded and
aligns with the AMD module bootstrapper.
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [ ] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
`flutter widget-preview start --web` will cause the widget preview
scaffold to be run as a Flutter Web application using experimental hot
reload support. This will eventually be the default, with the desktop
environment being put behind a flag for use as a fallback under the
assumption that the desktop environment will be removed in the future.
- Adds better instructions for hot reload (if using the right flags),
hot restart, quitting, clearing, and more. These were already being
printed when using the VM, so this aligns with that.
- Adds an extra parameter for `CommandHelp` to `ResidentRunner` so
`ResidentWebRunner` can pass a version of it that uses its separate
logger and not `globals`. In order to support this, classes up the stack
also provide a `Terminal`, `Platform`, and `OutputPreferences`.
- Fixes up use of `globals` from an earlier change to implement hot
reload to use the logger instead. Same with `globals.platform`.
- Adds tests to check that only hot restart is printed when not using
the extra front-end flags, and both hot restart and hot reload is
printed when you are.
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
- Delete code paths that handle screenshots for the HTML renderer
- Delete artifact enums for the HTML/AUTO renderers (and all their
usages).
- Remove HTML/AUTO renderers warnings.
- Delete the HTML/AUTO renderer enums (and all their usages).
- Delete tests for all the above.
Towards https://github.com/flutter/flutter/issues/162846.
Removes all of the unsound host artifacts, and then uses their name for
the sound artifacts.
That is, for something like `webPlatformDDCKernelDill`, this PR:
- Changes the web GN builders to only emit the sound SDK, without the
`-sound` suffixes
- Deletes `webPlatformDDCKernelDill` and all usages of it (implicitly
unsound, and unused).
- Renames `webPlatformDDCKernelSoundDill` to `webPlatformDDCKernelDill`.
No user impact expected, as there was no way to use the unsound
artifacts from the Flutter tool.
On an internal chat, I asked:
> Is there a reason I don't understand why `flutter` should still
support "unsound" null-safety modes?
@jonahwilliams:
> I don't believe its possible to have non-null safe flutter code.
---
There is quite a bit of code and branches, so to keep the PRs
understandable/approachable, this first PR removes the ability to have
the `DevFS` implementations for the web SDK choose between sound and
unsound null safety, and removes the mapping accordingly.
The enums still exist, but can be cleaned up in a follow-up PR (you'd
want to rename to remove "sound" as well, ideally).
https://github.com/flutter/flutter/issues/162567
- Uses the `bootstrapScript` field in `loadConfig` to run a script after
all scripts have loaded.
- This script just calls a callback that is set up beforehand and calls
main.
- Modifies the callback that calls `dartDevEmbedder.runMain` to wait
until both DWDS called main and all scripts have loaded.
- Unskips hot reload tests now that the race condition should no longer
exist.
## Pre-launch Checklist
- [ ] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [ ] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [ ] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [ ] I signed the [CLA].
- [ ] I listed at least one issue that this PR fixes in the description
above.
- [ ] I updated/added relevant documentation (doc comments with `///`).
- [ ] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [ ] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [ ] All existing and new tests are passing.
https://github.com/dart-lang/webdev/issues/2516
- Updates restart/reload code to accept a resetCompiler boolean to
disambiguate between whether this is a full restart and whether to reset
the resident compiler.
- Adds code to call reloadSources in DWDS and handle the response
(including any errors).
- Adds code to invoke reassemble.
- Adds code to emit a script that DWDS can later consume that contains
the changed sources and their associated libraries. This is used to hot
reload. The bootstrapper puts this in the global window. DWDS should be
updated to accept it in the provider itself. See
https://github.com/dart-lang/webdev/issues/2584.
- Adds code to parse module metadata from the frontend server. This is
identical to the implementation in DWDS % addressing type-related lints.
- Adds tests that run the existing hot reload tests but with web. Some
modifications are mode, including waiting for Flutter runs to finish
executing, and skipping a test that's not possible on the web.
Needs DWDS 24.3.4 to be published first and used before we can land.
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [ ] All existing and new tests are passing.
https://github.com/dart-lang/webdev/issues/2516https://github.com/dart-lang/webdev/issues/2561
- Adds logic to emit newly compiled sources to a file that can be read
by the bootstrapper.
- Adds bootstrapping logic to reload scripts as needed. This involves
implementing the necessary hot restart callback, fetching and processing
the emitted file of newly compiled sources, cache busting, and loading
the scripts onto the page. A lot of this logic is similar or identical
to what we have for internal hot restart support.
- Runs existing hot restart tests with the new bundle format.
- Adds meta tag to run with utf-8 like in
https://github.com/flutter/flutter/pull/161493.
- Uses DWDS 24.3.3.
## Pre-launch Checklist
- [X] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [X] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [X] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [X] I signed the [CLA].
- [X] I listed at least one issue that this PR fixes in the description
above.
- [X] I updated/added relevant documentation (doc comments with `///`).
- [X] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [X] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [ ] All existing and new tests are passing.
This test was merging two ZeroExecutionTimeValidationResults into a new
ValidationResult with an actual execution duration set rather than
Duration.zero.
Fixes https://github.com/flutter/flutter/issues/161918
The bootstrapping for the DDC module format and library bundle module
format contained a preamble to dynamically set the meta tag to ensure
the document is parsed as utf-8. This doesn't work as the page has
already been parsed at that point. Instead, it should go in the html
directly.
The meta tag should not affect the AMD module format, as require.js
already ensures any loaded scripts are parsed as utf-8.
This tag in general is needed to parse this string correctly:
https://github.com/dart-lang/sdk/blob/main/sdk/lib/core/uri.dart#L4100
This is a follow-up to PR
https://github.com/flutter/flutter/pull/161276.
## Pre-launch Checklist
- [X] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [X] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [X] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [X] I signed the [CLA].
- [X] I listed at least one issue that this PR fixes in the description
above.
- [X] I updated/added relevant documentation (doc comments with `///`).
- [ ] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [ ] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [ ] All existing and new tests are passing.
This gets us closer to enabling [hot
reload](https://github.com/dart-lang/sdk/issues/54934) on the web as
this format is a prerequisite. Historically, we added support for the
DDC module format only to enable hot reload, but that format is not
feasible for the goal, so we added the DDC library bundle format. The
DDC library bundle format is currently represented as the combination of
the `ddc` module format and `canary`. We no longer need to support the
old DDC module format.
- Adds build artifacts to build the SDKs for this format (but only in
sound mode as unsound is unsupported), and removes said artifacts for
the DDC module format.
- Update artifact maps and constants to add the new format and remove
the old format.
- Adds handling of the `canaryFeatures` flag.
- Update dwds to 24.3.0 and use the new
`FrontendServerDdcLibraryBundleStrategyProvider`.
- Add bootstrap code for the new format. Kept DDC module format
bootstrap code as it's used internally.
- Updates tests.
I ran `spinning_square` with the new module format to verify that it can
run.
## Pre-launch Checklist
- [X] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [X] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [X] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [X] I signed the [CLA].
- [X] I listed at least one issue that this PR fixes in the description
above.
- [X] I updated/added relevant documentation (doc comments with `///`).
- [X] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [ ] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [X] All existing and new tests are passing.
Now that "auto" is not supported anymore, it makes more sense to make
this dart define false by default. And there's no need to pass
`FLUTTER_WEB_AUTO_DETECT=false` anymore.
This auto-formats all *.dart files in the repository outside of the
`engine` subdirectory and enforces that these files stay formatted with
a presubmit check.
**Reviewers:** Please carefully review all the commits except for the
one titled "formatted". The "formatted" commit was auto-generated by
running `dev/tools/format.sh -a -f`. The other commits were hand-crafted
to prepare the repo for the formatting change. I recommend reviewing the
commits one-by-one via the "Commits" tab and avoiding Github's "Files
changed" tab as it will likely slow down your browser because of the
size of this PR.
---------
Co-authored-by: Kate Lovett <katelovett@google.com>
Co-authored-by: LongCatIsLooong <31859944+LongCatIsLooong@users.noreply.github.com>
Closes https://github.com/flutter/flutter/issues/158012.
This is (effectively) a user-facing NOP, which is exchanging an
on-by-default command-line argument (`--implicit-pubspec-resolution`)
for an off-by-default global feature flag
(`explicit-package-dependencies`). It matches the mental model better,
is less painstaking to maintain and feed throughout, and will be easier
to globally flip on/off in a future PR.
---------
Co-authored-by: Andrew Kolos <andrewrkolos@gmail.com>
Work towards https://github.com/flutter/flutter/issues/56591.
I explicitly want an LGTM from @andrewkolos @jmagman @jonahwilliams before merging.
---
After this PR, `<Plugin>.isDevDependency` is resolved based on the following logic, IFF:
- The plugin comes from a package _A_ listed in the app's package's `dev_dependencies: ...`
- The package _A_ is not a normal dependency of any transitive non-dev dependency of the app
See [`compute_dev_dependencies_test.dart`](51676093a3/packages/flutter_tools/test/general.shard/compute_dev_dependencies_test.dart) for probably the best specification of this behavior.
We (still) do not write the property to disk (i.e. it never makes it to `.flutter-plugins-dependencies`), so there is no impact to build artifacts at this time; that would come in a follow-up PR (and then follow-up follow-up PRs for the various build systems in both Gradle and Xcode to actually use that value to omit dependencies).
Some tests had to be updated; for the most part it was updating the default `ProcessManager` because a call to `dart pub deps --json` is now made in code that computes what plugins are available, but there should be no change in behavior.
_/cc @jonasfj @sigurdm for FYI only (we talked on an internal thread about this; see https://github.com/dart-lang/sdk/issues/56968)._
_/cc @camsim99 @cbracken @johnmccutchan for visibility on the change._
Work towards https://github.com/flutter/flutter/issues/157819. **No behavior changes as a result of this PR**.
Based on a proof of concept by @jonahwilliams (https://github.com/flutter/flutter/pull/157818).
The existence of this flag (which for the time being, defaults to `true`) implies the following:
1. The (legacy, deprecated) `.flutter-plugins` file is not generated:
https://docs.flutter.dev/release/breaking-changes/flutter-plugins-configuration
2. The (legacy, deprecated) `package:flutter_gen` is not synthetically generated:
https://github.com/flutter/website/pull/11343
(awaiting website approvers, but owners approve this change)
This change creates `useImplicitPubspecResolution` and plumbs it through as a required variable, parsing it from a `FlutterCommand.globalResults` where able. In tests, I've defaulted the value to `true` 100% of the time - except for places where the value itself is acted on directly, in which case there are true and false test-cases (e.g. localization and i10n based classes and functions).
I'm not extremely happy this needed to change 50+ files, but is sort of a result of how inter-connected many of the elements of the tools are. I believe keeping this as an explicit (flagged) argument will be our best way to ensure the default behavior changes consistently and that tests are running as expected.
Documents when to use `throwToolExit` and how to use it.
Replaces every invocation of `throw ToolExit` with `throwToolExit` and makes the former impossible; this is so that every user will at least (hypothetically) have the chance to read the documentation attached to `throwToolExit` (and if we change parameters in the future they will all flow through one place).
The SourceVisitor uses the engineVersion parameter to determine whether it needs to check for changes to artifacts or if it can assume that artifacts are unmodified from a versioned build of the engine. engineVersion is set based on whether the Artifacts instance sets the isLocalEngine property.
CachedLocalWebSdkArtifacts (instantiated when the --local-web-sdk flag is used) was only setting isLocalEngine if --local-engine was also used. This caused the build system to ignore changes to the files in the locally built flutter_web_sdk when using --local-web-sdk alone.
This PR renames Artifacts.isLocalEngine to usesLocalArtifacts in order to clarify what it means. It also changes CachedLocalWebSdkArtifacts to always enable usesLocalArtifacts.
There have been various requests for this for a while. See https://github.com/flutter/flutter/issues/96283 for an example. This has become more important with dart2wasm builds in the mix, as the profiling versions of the dart2wasm builds are a lot less debuggable than the debug versions. Most of this is already wired up so it just requires taking out a few explicit checks for it and making sure that we compile with the right optimization levels when compiling debug.
Dart2js updated its CLI to support generating a 'dump-info' json file by passing a "--stage" option. The "dump-info-all" stage performs a full compilation (from the provided dill) and then also generates the dump info file.
Tested via the `flutter-dev` CLI locally. This results in the same output but with the addition of an extra `main.dart.js.info.json` file.
Fixes https://github.com/flutter/flutter/issues/133585.
This PR elects to add a new catch within `_handleToolError` that checks any uncaught error. This new catch will exit the tool without crashing provided the following conditions are met:
1. the error is a `ProcessException`,
2. the error message contains `git` somewhere in the message (we don't match on the entire string in case it changes or is locale-dependent), and
3. `git` does not appear to be runnable on the host system (`ProcessManager.canRun` returns `false` for git).
This is preferable to checking for runnability of `git` before we run it for 1) its simplicity and 2) lack of performance penalty for users that already have git installed (almost every single one).
This PR also does some light refactoring to runner_test.dart to make room for tests that aren't related to crash reporting.
The choice screen is irrelevant when debugging apps locally. `flutter run` creates a separate user profile for testing only. It doesn't touch users' browser settings.
Fixes https://github.com/flutter/flutter/issues/153928
Fixes https://github.com/flutter/flutter/issues/153972 (unless the cause of https://github.com/flutter/flutter/issues/153064#issuecomment-2305662791 happens to also prevent this fix from working).
In this PR, I've looked for all non-test call sites of `ChromeConnection.getTabs` and made sure are all wrapped in `try` blocks that handle `IOException` (`HttpException` is what we see in crash reporting, but I figure any `IOException` might as well be the same for all intents and purposes).
I plan on cherry-picking this the stable branch.
This reverts commit 7cdc23b3e1bae2bc7bc2d1f34773eaa3629d4fcc.
The failure in the `native_assets_test` integration test on Windows was caused by the DevTools process not being shutdown by the `ColdRunner` when running the profile mode portion of the test. This resulted in the test being unable to clean up the project created by the test as DevTools was still holding onto a handle within the directory. This PR adds back the mistakenly removed DevTools shutdown logic in the `ColdRunner`.
Turns out just supporting the right value for `kDebugMode` was a lot simpler than I thought. Debug builds used to never go through the build system code path when using `flutter run`, but now that we have wasm this can occur with the run command.
This should address https://github.com/flutter/flutter/issues/148850
Reverts: flutter/flutter#146593
Initiated by: zanderso
Reason for reverting: Consistently failing `Windows_android native_assets_android` as in https://ci.chromium.org/ui/p/flutter/builders/prod/Windows_android%20native_assets_android/2533/overview
Original PR Author: bkonyi
Reviewed By: {christopherfujino, kenzieschmoll}
This change reverts the following previous change:
This change is a major step towards moving away from shipping DDS via Pub.
The first component of this PR is the move away from importing package:dds to launch DDS. Instead, DDS is launched out of process using the `dart development-service` command shipped with the Dart SDK. This makes Flutter's handling of DDS consistent with the standalone Dart VM.
The second component of this PR is the initial work to prepare for the removal of instances of DevTools being served manually by the flutter_tool, instead relying on DDS to serve DevTools. This will be consistent with how the standalone Dart VM serves DevTools, tying the DevTools lifecycle to a live DDS instance. This will allow for the removal of much of the logic needed to properly manage the lifecycle of the DevTools server in a future PR. Also, by serving DevTools from DDS, users will no longer need to forward a secondary port in remote workflows as DevTools will be available on the DDS port.
There's two remaining circumstances that will prevent us from removing DevtoolsRunner completely:
- The daemon's `devtools.serve` endpoint
- `flutter drive`'s `--profile-memory` flag used for recording memory profiles
This PR also includes some refactoring around `DebuggingOptions` to reduce the number of debugging related arguments being passed as parameters adjacent to a `DebuggingOptions` instance.
This change is a major step towards moving away from shipping DDS via
Pub.
The first component of this PR is the move away from importing
package:dds to launch DDS. Instead, DDS is launched out of process using
the `dart development-service` command shipped with the Dart SDK. This
makes Flutter's handling of DDS consistent with the standalone Dart VM.
The second component of this PR is the initial work to prepare for the
removal of instances of DevTools being served manually by the
flutter_tool, instead relying on DDS to serve DevTools. This will be
consistent with how the standalone Dart VM serves DevTools, tying the
DevTools lifecycle to a live DDS instance. This will allow for the
removal of much of the logic needed to properly manage the lifecycle of
the DevTools server in a future PR. Also, by serving DevTools from DDS,
users will no longer need to forward a secondary port in remote
workflows as DevTools will be available on the DDS port. This code is currently
commented out and will be enabled in a future PR.
There's two remaining circumstances that will prevent us from removing
DevtoolsRunner completely:
- The daemon's `devtools.serve` endpoint
- `flutter drive`'s `--profile-memory` flag used for recording memory
profiles
This PR also includes some refactoring around `DebuggingOptions` to
reduce the number of debugging related arguments being passed as
parameters adjacent to a `DebuggingOptions` instance.
This will make
* `flutter run` have source maps enabled by default
* `flutter build` have source maps disabled by default
which mirrors what happens already today with the js compilers.
For local development this works quite well - even better than with
dart2js (see dart2js issues in [0]).
We do have some follow-up items for source maps in dart2wasm compiler,
see [1]
[0]
[flutter/flutter/issues/151641](https://github.com/flutter/flutter/issues/151641)
[1]
[dart-lang/sdk/issues/56232](https://github.com/dart-lang/sdk/issues/56232)
https://github.com/flutter/flutter/pull/150645 tries to shut down Chrome by sending a browser close command through a debug protocol. The webkit_inspection_protocol library used to send the command may throw a SocketException if Chrome has already been shut down.
