Flutter Wrapper Support.

[Sunzxyong]

The Wrapper Workflow

Use the Flutter Wrapper to get the following benefits:

• Standardizes a project on a given Flutter version, each Flutter project has its own version of Flutter SDK
• Provides the same Flutter SDK version for different users and execution environments in a Flutter project

Flutter Wrapper contains the following files:

flutterw
flutterw.bat
flutter/wrapper/flutter-wrapper.properties

The layout of the Flutter project with Wrapper is as follows:

.
├── android
├── ios
├── lib/*.dart
├── pubspec.yaml
├── flutter
│   └── wrapper
│       └── flutter-wrapper.properties
├── flutterw
└── flutterw.bat

Develop in multiple projects

Develop in the team

More

See more information：Flutter Wrapper Workflow

[xster]

Tentative TBR @jonahwilliams?

[aam]

Is this to address #25979 ?

[jonahwilliams]

Some thoughts:

• When distributing a flutter version management system in the tool itself you can opt into a version which doesn't understand the version management. Or similarly Flutter on stable wouldn't have the correct scripts or be able to generate these wrappers..
• The copied entrypoint scripts will become stale and out of sync, I don't think this is the correct approach. Would it be more robust to distribute this as a separate program so that it can be used with stable flutter? For example, a dart script which was invoked via flutter pub run.
• Version information should probably go into a flutter specific pubspec field, so that this can be used with both applications and packages.

[Sunzxyong]

Some of my thoughts:

• I think stable Flutter version can generate "wrapper" files by extending the "flutter-intellij" plugin.
• The wrapper should be a separate program. The "flutter wrapper" version synchronizes "flutter sdk", and their relationship is similar to the one-to-one relationship, as follows:
  
  When updating "flutter sdk", just execute the './flutterw wrapper' or 'flutter wrapper' command to update its corresponding wrappers. This management method is the same as the gradle.

[dnfield]

Is this related to https://github.com/passsy/flutter_wrapper? Does it offer significant advantages over that project that warrant including it in the Flutter tooling? Do we have permission from the author of the original work to incorporate it this way?

[dnfield]

This code bears strong resemblence to code originally written by a different author under a different license. We need to make sure that author has signed a CLA and agrees to contribute the code to this repo under the terms of the CLA.

/cc @Hixie

[Sunzxyong]

This code has nothing to do with https://github.com/passsy/flutter_wrapper, i didn't know its existence before. It is my own original. This idea comes from gradle wrapper, when we started using Flutter, we have designed and used this method.
Please see my personal blog：Flutter componentization and engineering architecture

[Sunzxyong]

The advantages it offers:

• Standardizes a project on a given Flutter version, each Flutter project has its own version of Flutter SDK
• Provides the same Flutter SDK version for different users and execution environments in a Flutter project

[Sunzxyong]

We talked to @liyuqian about this management method before.

[passsy]

This PR has nothing to do with my passsy/flutter_wrapper besides that both have the same goal and both are very inspired by the gradle wrapper.

The main difference to passsy/flutter_wrapper is that flutter_wrapper doesn't require flutter or dart to install the flutter_wrapper. Everything is written in shell. But it requires a git repository to work.

The proposed wrapper here requires flutter to be installed to gernerate a wrapper. But it doesn't require git.

I'd be very happy if any of those solutions would become part of the official flutter project.

Passys comments

[dnfield]

Thanks @passsy and thanks for clarifying @Sunzxyong

I like the idea over all, and I definitely see how it could be usefu.

@Sunzxyong - do you think it would make sense to publish this as a package on pub rather than making it part of the framework and tooling? One disadvantage of having it being integrated into Flutter tooling is that it seems possible that a user might switch to a version of Flutter that doesn't support this feature and get stuck - whereas if it's a pub (global) package, they can update it independently of Flutter and not end up getting stuck in a version of Flutter that's missing it (or in a version of Flutter where this implementation has a bug).

[liyuqian]

Thanks @Sunzxyong for uploading the solution and thanks @dnfield for reviewing it! I agree that a separate pub package sounds like a better idea. That way, the team that's using an older Flutter (say 1.0) version could still use your solution 😄

[Sunzxyong]

Thanks to @dnfield @liyuqian and @passsy .
I think the separate pub package is also a good idea. This is not invasive to the flutter tools. I tried both ideas. This is what I am thinking about these two solutions:

1. For pub package

Use this method, the flutterw_manager is a separate pub package.
We have to execute the following two steps so that the flutterw_manager command can run directly:

1. add $HOME/.pub-cache/bin and ${FLUTTER_ROOT}/bin/cache/dart-sdk/bin in PATH
2. pub global activate flutterw_manager

After completion, We can generate or update wrapper files by running the following command in the Flutter project:

$ flutterw_manager generateWrapper

Advantages:

Support for any Flutter project.

Disadvantages:

Need to set environment variables and activate pub package.

2. For flutter tools

This method is supported by updating flutter_tools.
We can generate or update wrapper files by running the following command in the Flutter project:

$ flutter wrapper

Advantages:

Easy to use, just run the flutter wrapper command to generate the wrapper files in the Flutter project.
This is the same as the gradle wrapper

Disadvantages:

Need to update flutter_tools, so the old Flutter does not support.
Version control is missing.

Note

The methods above all generate wrapper files by running commands. Do we need to support the flutter-intellij plugin? like：

[Hixie]

I think it would make sense to make this available to people as an independent package that they can use with Flutter, but I think if we want to make this be part of Flutter itself, the way to do it is to have flutter run notice that the pubspec.yaml has a Flutter SDK constraint in its environment section, and then have it automatically check out the most recent appropriate version based on that, then re-run itself.

[jonahwilliams]

@Sunzxyong based on the discussion above I'm going to close this PR, but please don't hesitate to file further issues or feature requests for the tool.