This also wires up the preview detector to trigger hot reloads when new
previews are detected or previews are removed.
Note: while this change results in lib/generated_preview.dart being
generated and updated, it's not currently referenced by lib/main.dart
and the preview environment will render a black screen.
---------
Co-authored-by: Andrew Kolos <andrewrkolos@gmail.com>
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.
recompile has been split into recompile and recompile-restart in the
frontend server so that DDC can distinguish between hot reload
recompiles and hot restart recompiles, and therefore emit rejection
errors only on hot reload.
https://github.com/dart-lang/webdev/issues/2516
## 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/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.
Closes https://github.com/flutter/flutter/issues/161449.
~3 LOC, with 203 lines of tests (including an e2e integration test that
it actually works).
Feedback welcome!
(The reason I'm working on this is the ability to pass environment
variables makes it much easier and less hacky to make
`android_engine_test` configurable, i.e. have different expected outputs
for OpenGLES/Vulkan, compare screenshots locally for deflaking, etc).
imperative apply has been deprecated since #139690
part of #121541
Doing this will make things easier for us during the conversion of
`flutter.groovy` into Kotlin.
This PR rolls in a number of breaking changes from dart-lang/native:
* `BuildMode` is no longer part of the protocol, so Flutter no longer
passes it in.
* This means all code dealing with the name conflict between
`native_assets_cli.BuildMode` and `flutter_tools.BuildMode` has been
cleaned up.
* Also, the logs no longer mention the build mode.
* The tests still exercise both modes, because linking only happens in
release mode.
* `OS` is no longer part of the main protocol, but of the "code"
"protocol extension".
* The code now aligns more with `OS?` being nullable in a bunch of
places, since it is nullable if there's no code assets.
* The OS-specific config is nested in an object per OS.
* `CCompilerConfig`s fields are non-nullable now.
* So instead of passing an object with nullable fields around, a null
instead of the object is returned in various places.
* `FileSystem` is now passed in to the native assets builder.
This PR contains no feature changes.
This PR will need to be followed up by restricting what environment
variables are passed in (similar to
https://github.com/dart-lang/native/pull/1764), I will do this in a
follow up PR.
Tests:
* All existing features should be covered by existing tests.
dart_style 3.0.1 comes with some minor style fixes:
https://github.com/dart-lang/dart_style/blob/main/CHANGELOG.md#301
This PR applies this fixes in bulk across the repository. (Otherwise,
the next person touching these files would have been the one updating
them to the new format by running the formatter).
Work around: https://github.com/flutter/flutter/issues/160689.
I locally verified that we have not regressed what this was testing
(that just invoking `//flutter/bin/dart` will not build the flutter
tool).
In the future a hook may be invoked multiple times with different
`supportedAssetTypes` (soon to be renamed to `buildAssetTypes`).
The hook should only emit those asset types that are in
`supportedAssetTypes` - anything else is an error. Right now flutter
happens to invoke hooks only with `Code` asset types, but more asset
types are coming, for which this PR is a preparation for.
The integration test framework that waits for transitions and
(optionally) takes actions on transitions allows to match patterns.
If one uses a RegExp pattern than the framework only checks whether a
line contains the given RegExp pattern.
If one uses a String pattern it matches it exactly.
=> We add a `Barrier.contains()` and `Multiple.contains()` that allow
matching a line with if it contains the String (just like in RegExp)
=> This makes tests simpler as they don't have to know about the exact
padding of progres bar etc. Those may be irrelevant for the purpose of
the integration test and only complicate it.
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>
<!--
Thanks for filing a pull request!
Reviewers are typically assigned within a week of filing a request.
To learn more about code review, see our documentation on Tree Hygiene:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md
-->
**Description**
While exploring some semi-related stuff, found these 2 tests using
outdated regex which does not work because AGP version in modern
templates is set in `settings.gradle.kts` and in form of
`com.android.application` instead of `com.android.tools.build:gradle`.
Apart from that, in `android_plugin_example_app_build_test.dart` deleted
all lines regarding version change (instead of comply with new way of
declaring plugin) because for a long time it's didn't work anyway:
`replaceAll` haven't find any matches and test ran on latest AGP from
template. More than that, attempt to adapt this test to modern AGP setup
failed because build is not working with AGP < 8 (I lost logs with
actual error for this case, but I believe I can reproduce if anyone
wants)
in `native_assets_agp_version_test`:
- Fixed version to comply with AGP versioning format, which is
`major.minor.patch`.
- Updated regex and version changing logic to work with
`com.android.application` format and `settings.gradle.kts` file. I
believe that version updating is desired behavior here, unlike in
`android_plugin_example_app_build_test.dart`.
- Updated `kts` syntax for declaring flavors in `build.gradle.kts` and
updated regex-based updating of this file (didn't work previously
because there wasn't actual writing to file)
didn't list any issues because there're not any regarding these tests
(or maybe I just failed to find). In any case, I think that this doesn't
require issue because fix is kinda trivial and motivation is clear.
## 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].
- [ ] 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.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview
[Tree Hygiene]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md
[test-exempt]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes
[Discord]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md
[Data Driven Fixes]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md
This is the initial tooling work for Flutter Widget Previews, adding two
commands: `flutter widget-preview start` and `flutter widget-preview
clean`.
The `start` command currently only checks to see if
`.dart_tool/widget_preview_scaffold/` exists and creates a new Flutter
project using the widget_preview_scaffold template if one isn't found.
The widget_preview_scaffold template currently only contains some
placeholder files and will be updated to include additional code
required by the scaffold.
The `clean` command simply deletes `.dart_tool/widget_preview_scaffold/`
if it's found.
This change also includes some refactoring of the `create` command in
order to share some project creation logic without requiring `flutter
widget-preview start` to spawn a new process simply to run `flutter
create -t widget_preview .dart_tool/widget_preview_scaffold`.
Related issue: https://github.com/flutter/flutter/issues/115704
---------
Co-authored-by: Andrew Kolos <andrewrkolos@gmail.com>
Native asset tests use `flutter create --no-pub --template=package_ffi`.
The template used for this is checked in. It then adds extra
dependencies to checked-in packages in flutter/flutter (which have
pinned deps) in those generated templates.
It then pins all dependencies in the modified template project. This can
lead to constraint violations when flutter updates pinned dependencies,
because the template uses old constraints (which are turned from `^x` to
`=x`) and the additional dependency on flutter/flutter checked in
package brings in different pinned dependencies.
In a previous PR we already made this more robust by using flutter's
pinned versions over the the versions from the template (that are
changed from `^x` to `=x`).
Though a new upgrade of flutters pinned packages reveals that this isn't
quite sufficient: The template uses `test` at `^X`. The additional
dependency to `link_hook` doesn't depend on `test`. It therefore turns
it into `=X`. BUT `link_hooks` has a non-dev dependency on `test_core`
which is incompatible with `=X`.
=> So we relax this even more by prefering to choose (pinned) versions
of the flutter/flutter `link_hook` dependencies and (new) dev
dependencies over the template dependencies.
=> This will make use use the pinned `test` version from `link_hooks`
instead of from the template.
Killing the flutter_tools parent process may leak child processes
spawned by the tools.
Also wait for the message indicating that DevTools has started before
stopping flutter_tools. If DevTools has not fully launched, then there
may be a race between DevTools startup and flutter_tools shutdown.
Fixes https://github.com/flutter/flutter/issues/159154
Speculative fix for https://github.com/flutter/flutter/issues/157640.
A few observations:
- I was a bit paranoid about indented files meaning something was parsed
incorrectly
- I removed `android.enableR8=true` (not used elsewhere)
- I removed `android.experimental.enableNewResourceShrinker=true` (not
used elsewhere)
- I matched the rest of the `jvmargs` used in the standard template file
... let's hope this does good things?
Closes https://github.com/flutter/flutter/issues/158560.
I believe but am not sure as of
https://github.com/flutter/flutter/pull/159170 merging, many process
flakes that were consuming memory and in turn, making Gradle
particularly sensitive to timing out or being killing by the OS for
low-memory, have been rectified.
It is possible there are additional problems, but they aren't visible at
the moment.
I'd like to re-enable these and keep tracking their stability.
Towards https://github.com/flutter/flutter/issues/51421.
```sh
flutter_tools % dart test test/integration.shard/break_on_framework_exceptions_test.dart
02:38 +29: All tests passed!
54692 ttys003 0:00.02 /opt/homebrew/bin/zsh -il
```
Requires https://github.com/flutter/flutter/pull/159115 for the process
cleanup to work properly, but this is safe to land as-is, otherwise we
still accumulate `flutter` processes over and over as each test case
runs which is not WAI.
Towards https://github.com/flutter/flutter/issues/159000 as part of
debugging issues such as
https://github.com/flutter/flutter/issues/158560.
On a `bringup: true` shard, run a number of `flutter build apk` tests in
succession to try and routinely trigger timeouts and crashes, so we can
test other hypotheses on how to fix this problem (i.e. potentially
around increasing memory, changing daemon configuration, aggressively
killing processes, etc).
In the future, it will be possible for Swift Package Manager to be enabled on one but not all platforms (see https://github.com/flutter/flutter/issues/151567#issuecomment-2455941279).
This updates the `.flutter-plugin-dependencies` file format to separate iOS's and macOS's SwiftPM enablement. For now, these platforms will always have the same value.
This `.flutter-plugin-dependencies` file is read by our CocoaPods scripts to determine whether we should use CocoaPods or not to inject plugins.
Part of https://github.com/flutter/flutter/issues/151567
**PR Title:**
Remove block and line comments when detecting `'.flutter-plugins'` in `settings.gradle`
---
**Description:**
This PR modifies the `configureLegacyPluginEachProjects` function to remove block (`/* ... */`) and line (`// ...`) comments from the `settings.gradle` or `settings.gradle.kts` file content before checking for the presence of the `'.flutter-plugins'` string. This ensures that only uncommented, meaningful code is considered during the detection, preventing false positives when the string appears within comments.
**Why is this change necessary?**
In some cases, the `'.flutter-plugins'` string may be present inside comments in the `settings.gradle` file. The existing implementation does not account for this and may incorrectly detect the string even when it's commented out. This can lead to unintended behavior, such as configuring plugin projects when it is not necessary.
By removing comments before performing the check, we prevent false positives and ensure that the detection logic is accurate, only acting when the `'.flutter-plugins'` string is present in active code.
**Changes Made:**
- **Added comment removal logic:**
- Removed block comments (`/* ... */`) using the regular expression `/(?s)\/\*.*?\*\//`.
- The `(?s)` flag enables dot-all mode, allowing `.` to match newline characters.
- Removed line comments (`// ...`) using the regular expression `/(?m)\/\/.*$`.
- The `(?m)` flag enables multi-line mode, so `^` and `$` match the start and end of each line.
- Combined both comment removal steps into a single chain for efficiency.
- **Updated the string detection:**
- The check for `'.flutter-plugins'` is now performed on the uncommented content of the `settings.gradle` file.
- This ensures that only meaningful, uncommented code is considered during detection.
**Issue Fixed:**
- Fixes [#155484](https://github.com/flutter/flutter/issues/155484)
---
---
If you need any further assistance or have questions, feel free to reach out!
---
**Links:**
- [Contributor Guide]
- [Tree Hygiene]
- [Flutter Style Guide]
- [Features we expect every widget to implement]
- [CLA]
- [flutter/tests]
- [breaking change policy]
- [Discord]
- [Data Driven Fixes]
