Skip to content

Should we revert PreviewDevice (and associated code)? #162693

@matanlurey

Description

@matanlurey

I am working on a totally unrelated set of features in #162649.

As part of this, I noticed that <FlutterCommand>.verifyThenRunCommand always checks for "allowed plugins":

// null implicitly means all plugins are allowed
List<String>? allowedPlugins;
if (stringArg(FlutterGlobalOptions.kDeviceIdOption, global: true) == 'preview') {
// The preview device does not currently support any plugins.
allowedPlugins = PreviewDevice.supportedPubPlugins;
}
await project.regeneratePlatformSpecificTooling(
allowedPlugins: allowedPlugins,

This is problematic, today regeneratePlatformSpecificTooling is called once (implicitly when --no-pub is omitted), even on so-called "meta builds" such as flutter build aar or flutter build ios-framework which, by default, build debug, profile, and release mode builds.

With an upcoming change (--explicit-pacakge-dependencies), we need to inform regeneratePlatformSpecificTooling what the current build mode is. So, this code to regenerate platform specific tooling needs to be run differently for meta-builds. @andrewkolos mentioned this project is on indefinite hiatus, so if so, should we revert/remove the associated code (it can always be restored via Git-foo in the future)?

@christopherfujino assigning to you - if you are OK with this revert, LMK, otherwise we can chat further.

Metadata

Metadata

Assignees

Labels

P1High-priority issues at the top of the work listc: tech-debtTechnical debt, code quality, testing, etc.team-toolOwned by Flutter Tool team

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions