Do people check their generated files into Git?

[colinhacks]

Seems like most of the internet says "don't check generated files into version control". Ostensibly to avoid having the "canonical" code (e.g. GraphQL schema) get out of sync with the generated artefacts (whatever gets produced by graphql-code-generator).

But if I don't check in those files, then checking out a new branch will leave the generated files from the old branch in my file system. Unless I'm extremely disciplined about re-running codegen after switching branches, the code may break in unexpected ways.

Seems like a catch-22. I can't find any best practice on this.

[dotansimha]

Hi @vriad !

Personally, I prefer not to put generated files under source control. It bloats the repository and increase the size. It also causes merge conflicts in a lot of cases.
When possible (for example: your schema is available without running the server), I prefer to run Codegen as part of the CI and build system.

I usually create pre script (in package.json) for my start and build commands, so if you switch branch, it will run codegen again right before running the actual project. This way you avoid the need to run it manually or remember to run it after changing branches.

[jamesonhill]

Are you using .gitignore?

[dotansimha]

Yeah, all generated files are ignored for our projects.

[Axedyson]

I use typegraphql to generate my schema.graphql file. Should I upload that file to git or should I try to generate that as part of CI alongside the process of typescript code generation by graphql-code-gen?

[eremzeit]

To me it seems like types (whether they are auto-generated or manually written) are directly coupled to the correct building of the codebase so they should be checked in. If you don't check them in, then you open up the possibility of two separate developers having checking out the same commit and getting two different results when they build.

dotansimha says that he does't check-in types, but it seems like he can get away with this only because:

1. he aggressively generating the types before every start or build of the server
2. He builds from static assets...
3. that are defined in a monorepo.

If you are working in a codebase that doesn't have those three properties then I believe you will have problems that dannycochran mentions about reproducible builds and commits.

[q3769-patientpoint]

If you don't check them in, then you open up the possibility of two separate developers having checking out the same commit and getting two different results when they build.

If your source of generation e.g. an Avro schema file is versioned/checked-in, and the code generator e.g. the Avro code-gen tool is also versioned/checked-in together with the source as they are in the same code repo, then how can two devs checking out the same commit get two different results when they build? The co-versioned schema source file and code-gen tool library collectively guarantee idempotent uniqueness of the code generated on-the-fly during the build, no?

[colinhacks]

Ah great stuff! The pre- hooks are awesome, didn't know about those. Thanks!

[JustFly1984]

@dotansimha @dannycochran @jamesonhill @colinhacks We are checking in generated files, but do not import from them. Some types generated are completely wrong, and there is a lot of inlined styles generated. Also generated code contains a lot of any types, which should be improved.

You should not edit generated files, and I would not recommend you to import from generated files too for reasons described above.

I'm checking generated files into the repo, so I can see the diff, and improve edited version accordingly. Yes it is more tedious work, but tools are not perfect yet. I've created a discussion #6741 about some incorrect types generated from schema.

[eremzeit]

To me it seems like types (whether they are auto-generated or manually written) are directly coupled to the correct building of the codebase so they should be checked in. If you don't check them in, then you open up the possibility of two separate developers having checking out the same commit and getting two different results when they build.

@dotansimha says that he does't check-in types, but it seems like he can get away with this only because:

• he is aggressively generating the types before every start or build of the server
• He builds from static assets (rather than from a running server instance)
• ...that are defined in a monorepo (ie. there won't be changes to the BE code that happen without the FE devs being aware)

If you are working in a codebase that doesn't have those three properties then I believe you will have problems that @dannycochran mentions about reproducible builds and commits.

[eremzeit]

If regenerating types causes excessive diff churn every time it happens then maybe something could be optimized with the code generation? In theory, a small change in a query should result in only a small change in a generated file. The same principle would apply if any developer were updating types by-hand for some hypothetical RESTful API. If there was only a small change to shape of the API, then the developer should avoid refactoring the entire file but only make a diff on what's actually changing.