Should I commit generated code in Flutter/Dart to VCS

Question

I'm using the Retrofit (https://pub.dev/packages/retrofit) and Json Serializable (https://pub.dev/packages/json_serializable) libraries for Flutter which both create generated code files that end up amongst the rest of the source code. Should the generated x.g.dart files be committed in VCS?

In normal Android/Java development the generated files go into special gen/out/build folders that you don't commit and the IDE is usually pretty good at hiding these files. But since Flutter generates them in the source I'm not sure what to do with them.

Answer 1

Update: one reason you may want to ignore them from git commits is when you don't want them to be shown in pull requests which are being code reviewed. in this case you ignore generated files from git commit in your project.

TLDR: if you add generated files to your git commits, and then hit any problems (which you rarely do) all you need to do is run build_runner with the flag --delete-conflicting-outputs

flutter packages pub run build_runner build --delete-conflicting-outputs

Problems of adding generated files to Git commits And how to deal with them

the mentioned build_runner documentation point on not adding generated files to your git commits is not a good point. which later i say why.

the point of adding generated files is not to be have to run build_runner each time you do a git pull or change branches since the source files have been changed or new source files have been added by your fellow developers and you need to run build_runner to generate files for source files to be able to run the code without errors.

but what happens if you decide to add generated code to your git commits? and how can you easily solve them.

first problem is you might confront a merge conflict in a generated file. now how do you deal with this. you dont't. at this point you just resolve conflicts in the source file (if any) and then run build_runner and the gnerated files will be generated again.

the other problem is what mentioned in builder_runner docs. which is when you run build_runner and it gives you this error

C:\workspace\flutter\projects> flutter pub run build_runner build
[INFO] Generating build script...
[INFO] Generating build script completed, took 336ms

[WARNING] Deleted previous snapshot due to missing asset graph.
[INFO] Creating build script snapshot......
[INFO] Creating build script snapshot... completed, took 12.5s

[INFO] Initializing inputs
[INFO] Building new asset graph...
[INFO] Building new asset graph completed, took 787ms

[INFO] Checking for unexpected pre-existing outputs....
[INFO] Found 13 declared outputs which already exist on disk. This is likely because the`.dart_tool/build` folder was deleted, or you are submitting generated files to your source repository.
[SEVERE] Conflicting outputs were detected and the build is unable to prompt for permission to remove them. These outputs must be removed manually or the build can be run with `--delete-conflicting-outputs`. The outputs are: lib/models/advisory-service-item.g.dart

which you can easily solve buy adding --delete-conflicting-outputs flag when running build_runner. like we do many times already

flutter packages pub run build_runner build --delete-conflicting-outputs 

So for either problems you run the above command, that's it

Answer 2

TLDR: The flutter tooling is not advanced enough for this. Working around this today would add more complexity to your project. Generally committing source code is a debatable opinion, see Should I store generated code in source control, but for Flutter specifically, it is very much in favour of keeping the generated source code files in git.

• Current practices: Google developers working on a flutter plugin package (video_player) have committed generated files to their repository.
• Tool limitation: flutter run does not seem to support running codegen on compilation / build, so you're asking users to manually run code generation when copying the repo, writing a script and asking users to do this (and making IDE support worse/tedious), or setting up a client side or server side Git hook. These are all complexities to solve what problem actually? The fact that in other ecosystems you don't commit generated files?
  • causes extra configuration: You may add more configuration work (and skill required) to set up an IDE correctly. Of course, a good developer can share their configuration by putting Android Studio configuration in the git repo, but Flutter developers may expect to be able to run flutter run.
• Convention over configuration: Would a developer who starts in your project need to manually run code generation or use a specific IDE that you use then? Or learn how to configure their IDE of choice to launch the app? In that case, we are adding overhead to the developer who works on this project. Aim for simplicity, not just for your sake, but everyone else's sake.
• Lowest common denominator output: Flutter is different to Android / Gradle (or other ecosystems), and we should not try to make things consistent (standardise) at the cost of getting the lowest common denominator output. Flutter does not have a flutter sync command that is automatically run by the IDE when it launches, so there is no way to run this code generation automatically.

Existing discussion: There is a discussion on Flutter about improving the code generation experience (https://github.com/flutter/flutter/issues/63323). Committing generated files is such a small aspect of a feature.

Answer 3

It is best not to commit the generated files generally. As recommended by the build_runner itself. Here is the link to the source control section of the package.

Also, it mentions two things to consider.

1. A specific builder's recommendation should supersede these recommendations if different.
2. In some case generated files can cause 'already exists' warnings. I have seen this myself multiple times.

Answer 4

if you are building app on your own CI and you are not publishing it as package (on github) I would not commit them and just generate them each time on CI during publish. You really don't want to resolve conflicts on generated code.

Answer 5

It's necessary to commit generated files. If we did not commit and support we are using Jenkins then build will not generate as part files are missing.