Hi! Thanks for opening this pull request! 😄

@fzyzcjy could I get your thoughts on this PR when you have the chance? Not sure if I covered all the related changes for a release - if any changes are needed to adjust generation of frb_codegen/assets/integration_template/shared. If all looks good, I can update the docs and change status to ready for review.

Good job! Some nits

• Maybe we can make integrate and create use the same flag (e.g. both use template) to avoid confusion. (Or, do you choose type because there are some conventions there)
• To test it, try to mimic how flutter_via_create is tested. More specifically, (1) add a line probably below

  flutter_rust_bridge/tools/frb_internal/lib/src/makefile_dart/consts.dart

  Line 31 in b68eb1d

  'frb_example/flutter_via_integrate',

  (2) Add a line below

  flutter_rust_bridge/.github/workflows/ci.yaml

  Line 242 in b68eb1d

  - frb_example--flutter_via_integrate

  . The test may name flutter_package. The "generate_run_frb_codegen_command_integrate" test means nothing but "let's run the codegen create/integrate command and check the result agrees with existing code".

You can test any CI thing locally by copy-paste-run the ./frb_internal ... command in corresponding CI section.

@fzyzcjy2 Thanks for the feedback!

• Changed to template
• Added tests

This should be ready for review. I was unable to get some commands with ./frb_internal working locally like ./frb_internal precommit --mode slow or ./frb_internal generate-run-frb-codegen-command-integrate --set-exit-if-changed --package frb_example--flutter_via_integrate --coverage. Issues seem to stem from running in dev container, and also running flutter 3.22.2. Side note: fvm does not currently work in dev containers (I run NixOs so dev containers are a must) issue link. So I had to update flutter_package manually which will likely fail the ci since the ci is using 3.22.0. Rather than further banging my head against a wall to get things to work in my environment, I'd ask you or someone else to make the project file changes that satisfy the git diff tests. Running everything by hand locally looks fine though.

In the future, we may want to separate flutter_package into flutter_package_via_create and flutter_package_via_integrate like you did with flutter_via_create and flutter_via_integrate. But I do think diff testing may be a development bottleneck and I recommend creating projects then invoking their integration_test suites instead. But that is just a matter of opinion.

Also, it may be worth while to attach a dev Containerfile to the this project for development. That way local dev and ci dev can be seamless. I know I would appreciate it.

Looks great! (Btw you mentioned the wrong account ;) that account is to auto publish new versions of flutter_rust_bridge).

Ok, I will run the diff generation later.

But I do think diff testing may be a development bottleneck and I recommend creating projects then invoking their integration_test suites instead.

IMHO we do diff testing because, we want to know whether the codegen create command really works or not.

Also, it may be worth while to attach a dev Containerfile to the this project for development. That way local dev and ci dev can be seamless. I know I would appreciate it.

That's interesting, and feel free to PR for this!

Looks great! (Btw you mentioned the wrong account ;) that account is to auto publish new versions of flutter_rust_bridge).

Oh haha my bad.

Ok, I will run the diff generation later.

Thanks!

IMHO we do diff testing because, we want to know whether the codegen create command really works or not.

Well the best way to test if it works IMHO is to actually run the code. That's what I meant by

I recommend creating projects then invoking their integration_test suites instead.

Like

flutter_rust_bridge_codegen create flutter_package --template plugin &&
flutter test flutter_package/example/integration_test/simple_test.dart &&
rm -r flutter_package

(probably best run the test for each platform).
rather than running into constant diff discrepancies.

That's interesting, and feel free to PR for this!

I may do that. I could get started at least, write a ticket for what needs to be done and setup rust/flutter in a Containerfile and .devcontainer. Then someone else may be best take over from there. Not super familiar with github ci or additional dev dependency issues I ran into earlier.

This should be good to review again/respond to my responses.

Well the best way to test if it works IMHO is to actually run the code.

We have two things on ci indeed:

1. diff test: generate it and see it matches
2. running test: run and test the commited code

I may do that. I could get started at least, write a ticket for what needs to be done and setup rust/flutter in a Containerfile and .devcontainer. Then someone else may be best take over from there. Not super familiar with github ci or additional dev dependency issues I ran into earlier.

That looks pretty reasonable!

Codecov Report

Attention: Patch coverage is 0% with 165 lines in your changes missing coverage. Please review.

Project coverage is 96.30%. Comparing base (a1328d3) to head (4a99351).

@@            Coverage Diff             @@
##           master    #2144      +/-   ##
==========================================
- Coverage   99.08%   96.30%   -2.79%     
==========================================
  Files         486      487       +1     
  Lines       19991    20029      +38     
==========================================
- Hits        19809    19289     -520     
- Misses        182      740     +558     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@all-contributors please add @mcmah309 for code

@fzyzcjy

I've put up a pull request to add @mcmah309! 🎉

Hi! Congrats on merging your first pull request! 🎉

Update: #2156 (comment)