[CP-stable][ Widget Preview ] Always generate scaffold under $TMP (#179039)
#179050
Conversation
Since `flutter clean` can delete the `.dart_tool/` directory while a `flutter widget-preview start` command is active, it's possible for the `widget_preview_scaffold` to be deleted and cause the preview process to crash. This change works around this issue by always generating the `widget_preview_scaffold` project under $TMP on each invocation of the previewer. This doesn't result in much of a regression in startup times as we currently aren't launching the previewer using restored state as this isn't currently possible with the web device targets. Moving the scaffold under $TMP means Flutter tooling will never accidentally delete the scaffold while the previewer is running. Filed #179036 to track reverting this behavior when a better solution is found. Fixes #175058
|
This pull request was opened from and to a release candidate branch. This should only be done as part of the official Flutter release process. If you are attempting to make a regular contribution to the Flutter project, please close this PR and follow the instructions at Tree Hygiene for detailed instructions on contributing to Flutter. Reviewers: Use caution before merging pull requests to release branches. Ensure the proper procedure has been followed. |
github-actions
bot
added
the
tool
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request fixes a crash in the widget previewer when flutter clean is run. The fix involves moving the widget preview scaffold project from the project's .dart_tool directory to a system temporary directory, which isolates it from flutter clean. Consequently, several related changes were made to handle absolute paths for assets and project dependencies, and tests were updated accordingly, including a new regression test for the original issue. My review found that this change inadvertently breaks the widget-preview clean command, which no longer cleans up the correct directory. Given that the temporary directory is now auto-cleaned on process exit, the clean command might be obsolete or need a redesign.
bkonyi
changed the title
$TMP (#179039)$TMP (#179039)
bkonyi
changed the title
$TMP (#179039)$TMP (#179039)
Removed project parameter from PreviewDetector initialization.
Refactor widget preview test to ensure proper handling of package_config.json and simulate interrupted flutter widget-preview start.
eyebrowsoffire
added
the
autosubmit
2 participants
This pull request is created by automatic cherry pick workflow
Please fill in the form below, and a flutter domain expert will evaluate this cherry pick request.
Issue Link:
What is the link to the issue this cherry-pick is addressing?
#175058
Changelog Description:
Explain this cherry pick in one line that is accessible to most Flutter developers. See best practices for examples
flutter widget-preview startcan crash ifflutter cleanis run while the widget previewer is running.Impact Description:
What is the impact (ex. visual jank on Samsung phones, app crash, cannot ship an iOS app)? Does it impact development (ex. flutter doctor crashes when Android Studio is installed), or the shipping production app (the app crashes on launch)
The widget previewer can silently crash in IDEs if the user runs
flutter cleanon the project. There's no indication that the previewer has crashed other than the fact that the previewer no longer hot reloads when the user make changes to their previews.Workaround:
Is there a workaround for this issue?
Not running
flutter cleanwhile the widget previewer is running, or restarting the IDE afterflutter cleanis run.Risk:
What is the risk level of this cherry-pick?
Test Coverage:
Are you confident that your fix is well-tested by automated tests?
Validation Steps:
What are the steps to validate that this fix works?
flutter widget-preview startflutter cleanand verify theflutter widget-preview startprocess doesn't crash.