search

olexale / bdd_widget_test

A BDD-style widget testing library
MIT License
101 stars 30 forks source link

How to avoid code formatting for generated test files? #77

Closed haashem closed 5 months ago

haashem commented 5 months ago

Hi,

In my CI workflow, the first step I have added is code formatting using the command dart format -o none --set-exit-if-changed ., which stops the CI process if the code is not formatted correctly. However, the CI always fails because the generated test files are not formatted.

Is it possible to add an option to postfix the generated files with .g.dart so I can exclude them from being committed? Alternatively, how do you suggest I solve this issue?

code format

olexale commented 5 months ago

Hello @haashem,

First, of all, upvote this issue as the dart formatter does not support this. For now, here is a workaround to avoid formatting some files: https://github.com/dart-lang/dart_style/issues/864#issuecomment-1906583340

Is it possible to add an option to postfix the generated files with .g.dart so I can exclude them from being committed?

You may add .g.dart files to .gitignore, however, on large projects, I wouldn't recommend that.

haashem commented 5 months ago

Thanks for quick reply and sorry for my late reply back,

What do you think about pushing a PR which makes the generated code already formatted? if you are fine I try to create a PR.

-- I'm interested to know your opinion why the generated code should not be added to the .gitignore?

olexale commented 5 months ago

I try to keep as few dependencies as possible for this package, however, I see a decent amount of engineers complaining about non-formatted generated code. dart_style seems to be a perfect package that will do the trick. I can take a look at it during the weekend. If you raise a PR before that — even better.

I'm interested to know your opinion why the generated code should not be added to the .gitignore?

I haven't said that. 🙂 There is always a tradeoff. If you ignore generated files in .gitignore, you will not have merge conflicts caused by changes in generated code, and there will be less noise in PRs and in the repo. If you commit generated files, your project will be in the "ready to compile" state right after you pull it from the remote repo, plus you would not need to wait for code generation to complete its job.

So, you need to choose the problems you want to have. I chose to commit files as I treat generated code as code that I need to maintain and I prefer to know what exactly I maintain (i.e. I don't trust CI to generate it for me). Not to mention that on some projects code generation might take a significant amount of time, so you may consider it as an optimization.