-
Notifications
You must be signed in to change notification settings - Fork 29.7k
[tools][web] Make Plugin Registrant file ephemeral. #102185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[tools][web] Make Plugin Registrant file ephemeral. #102185
Conversation
|
|
|
They did explode, but more broke because of the unconditional write of the registrant, than its contents! (Fixed) |
|
I am not too familiar with the nuances of plugin registration logic, so while this PR LGTM I recommend getting LGTMs from @stuartmorgan and/or @christopherfujino. |
|
Some recent changes to address PR comments:
I hope I've addressed your comments @stuartmorgan, PTAL! |
|
(Rebased after 944fcda) |
|
PTAL @stuartmorgan? Thanks! |
stuartmorgan-g
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with comment nits, with the caveat that I'm not very familiar with how the web bootstrapping works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't you mean not required at project generation time? If not, I'm not sure what the distinction between "compile time" and "build time" is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think I'm going to use "project creation time" and "build time", I can't think of better names :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also specified a little bit better what the actual difference between the two methods is:
- one writes the generated plugin registrants in locations configured by each
FlutterProjectsubclass, - the other writes the generated plugin registrant (later) and within the temp directory of the build in progress (maybe to a real filesystem, or to an in-memory one)
Jasguerrero
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Fix imports.
Fix flutter build + flutter run scripts to use the new generation function, instead of their hardcoded versions.
(This shouldn't be needed, since the generated files live outside of the main app's lib directory, and are only created when doing flutter run/build, but it's good practice that generated files don't interfere with user code anyway.) Fixes #99952
The file is now ephemeral, and generated only as needed, so there's no need for this gitignore to exist anymore.
Prevent ensureReadyForPlatformSpecificTooling from calling injectPlugins for the web, since at this point on the build we don't have enough info. Flutter web commands (build, run) know when to call injectPlugins.
* Remove webPlatform from injectPlugins, to remove a foot gun from the execution path. * Introduce injectBuildTimePluginFiles with a similar signature to injectPlugins so web (and maybe others?) can inject the plugin files it needs, when needed. * Always inject a web plugin registrant, either a NOOP, or something that actually registers plugins, to decrease tooling complexity down the line (when generating a main entrypoint, for example) * Cleanup of other unneeded things (like the buildDir property on the WebProject, that is now an argument passed to injectBuildTimePluginFiles. * Test injectBuildTimePluginFiles.
…ritten unconditionally.
… and hook it up at the beginning of the compile process, where the file used to be generated.
|
(Applying the correct tag this time 😅) |
) The Flutter CLI removes the `app/lib/generated_plugin_registrant.dart` automatically from `.gitignore` because it does not exist anymore, see flutter/flutter#102185. ``` $ flutter build web Running "flutter pub get" in flutter_example... 1,041ms 💪 Building with sound null safety 💪 generated_plugin_registrant.dart found. Deleted. Upgrading .gitignore Compiling lib/main.dart for the Web... 8.5s ``` This PR removes the `lib/generated_plugin_registrant.dart` from `.gitignore` as the Flutter CLI does when building for web.
This change modifies flutter_tool slightly to make the
web_plugin_registrant.dartfile ephemeral (only created when needed, and not left in the users' working copy).I needed to do some changes to the way a FlutterWeb Project works so it supports both modes of operation (on-disk for
flutter buildandin-memoryforflutter run) so we can configure where theflutter_plugins.dartcode creates the plugin registrar file for the web. Hence why it'd be nice that @blasten and @stuartmorgan took a quick look if possible :)PluginMigrator
As suggested by @stuartmorgan, this change also adds a
ProjectMigrator(classScrubGeneratedPluginRegistrant) that deletes the oldlib/generated_plugin_registrant.dartfile if it exists, and cleans the.gitignorefile by removing lines that are equal to:'lib/generated_plugin_registrant.dart'.The migrator runs when the user does
flutter build web(only), with the following output:More changes (cleanup)
file_generatorssubdir, and moves there the file that generatesflutter.jsfile_generators)file_generators)assets/NOTICES. Issue.main.dartandweb_plugin_registrar.dart), and ensures they won't triggerlintwarnings. Issue.generated_plugin_registrar.dartfrom.gitignoretemplate for new projects, now that it is created on-demand.Issues
Tests
WIP, this PR has been created in part to see where things burst at the seams :)
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.