Skip to content

Conversation

@ditman
Copy link
Member

@ditman ditman commented Apr 20, 2022

This change modifies flutter_tool slightly to make the web_plugin_registrant.dart file 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 build and in-memory for flutter run) so we can configure where the flutter_plugins.dart code 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 (class ScrubGeneratedPluginRegistrant) that deletes the old lib/generated_plugin_registrant.dart file if it exists, and cleans the .gitignore file 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:

$ 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

More changes (cleanup)

  • Creates a file_generators subdir, and moves there the file that generates flutter.js
    • Unifies the code that generates the main entrypoint of a web app (and puts it in a file under file_generators)
    • Extracts the code that generates the service worker (and puts it in a file under file_generators)
  • Prevents the service worker from prefetching assets/NOTICES. Issue.
  • Simplifies the web entrypoints a little bit (main.dart and web_plugin_registrar.dart), and ensures they won't trigger lint warnings. Issue.
  • Removes generated_plugin_registrar.dart from .gitignore template 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

  • 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.
  • All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@flutter-dashboard flutter-dashboard bot added the tool Affects the "flutter" command-line tool. See also t: labels. label Apr 20, 2022
@ditman ditman requested a review from yjbanov April 20, 2022 01:20
@ditman ditman added the platform-web Web applications specifically label Apr 20, 2022
@ditman
Copy link
Member Author

ditman commented Apr 20, 2022

Null check operator used on a null value I probably forgot to check some entrypoint (or maybe tests are attempting to run some stuff for web without pre-configuring the FlutterProject earlier)

@flutter-dashboard flutter-dashboard bot added the c: contributor-productivity Team-specific productivity, code health, technical debt. label Apr 20, 2022
@ditman ditman marked this pull request as ready for review April 20, 2022 23:30
@ditman
Copy link
Member Author

ditman commented Apr 23, 2022

I seem to recall that I have at least two tests that test for the non-existence of the web_plugin_registrant, but can't find them right now... They'll eventually explode in CI, I guess :)

They did explode, but more broke because of the unconditional write of the registrant, than its contents! (Fixed)

@yjbanov
Copy link
Contributor

yjbanov commented Apr 23, 2022

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.

@ditman
Copy link
Member Author

ditman commented Apr 26, 2022

Some recent changes to address PR comments:

  • Added a ProjectMigrator to scrub generated_plugin_registrant.dart
  • Separated injectPlugins from injectBuildTimePluginFiles
    • injectPlugins does not support webPlatform anymore.
    • injectBuildTimePluginFiles has a signature very similar to injectPlugins, in case it can be reused for other platforms. It only supports webPlatform for now.
  • Create a noop web_plugin_registrar.dart when the app has no plugins, so the rest of the build process doesn't need to care about the project having plugins or not.

I hope I've addressed your comments @stuartmorgan, PTAL!

@ditman
Copy link
Member Author

ditman commented Apr 26, 2022

(Rebased after 944fcda)

@ditman
Copy link
Member Author

ditman commented May 4, 2022

PTAL @stuartmorgan? Thanks!

@ditman ditman requested review from Jasguerrero and removed request for christopherfujino May 9, 2022 19:44
Copy link
Contributor

@stuartmorgan-g stuartmorgan-g left a 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.

Copy link
Contributor

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.

Copy link
Member Author

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 :/

Copy link
Member Author

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 FlutterProject subclass,
  • 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)

Copy link
Contributor

@Jasguerrero Jasguerrero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

ditman added 12 commits May 10, 2022 18:18
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.
ditman added 6 commits May 10, 2022 18:18
* 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.
… and hook it up at the beginning of the compile process, where the file used to be generated.
@ditman
Copy link
Member Author

ditman commented May 12, 2022

(Applying the correct tag this time 😅)

@fluttergithubbot fluttergithubbot merged commit 1af8cc1 into flutter:master May 12, 2022
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request May 12, 2022
@ditman ditman deleted the tools-make-plugin-registrant-ephemeral branch May 12, 2022 04:38
engine-flutter-autoroll added a commit to engine-flutter-autoroll/plugins that referenced this pull request May 12, 2022
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Aug 30, 2022
engine-flutter-autoroll added a commit to engine-flutter-autoroll/plugins that referenced this pull request Aug 30, 2022
nilsreichardt added a commit to SharezoneApp/sharezone-app that referenced this pull request Mar 13, 2023
)

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

c: contributor-productivity Team-specific productivity, code health, technical debt. platform-web Web applications specifically tool Affects the "flutter" command-line tool. See also t: labels.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

web: Service worker downloads NOTICES file directly at the start of the application [Proposal] Disable linting for generated_plugin_registrant.dart

5 participants