Idea: bot that pretty prints on commit

[vjeux]

I was thinking in the context of a github project, how to make sure that the files stay pretty printed.

The most obvious way is to add a CI rule that fails if the file is not pretty printed, but in practice that's super annoying as you only get the feedback way later and don't even get an email notification that it failed.

Instead, I was thinking of letting maintainers merge non pretty printed files and then have a CI hook that pretty prints all the changed files. If there's a change, then have a bot commit the pretty printed version to master directly.

Because github doesn't check the author field, we can even have the commit under the original author name and link to the actual commit to make sure that the blame and attribution is clean.

I'd love thoughts on this, is this crazy?

[hzoo]

Not crazy, was thinking about a bot for this for eslint --fix for a long time. For our newly created https://github.com/babel/babel-bot we want to comment with the log failure and I thought if we could check the logs (not sure the most cost effective) to see if a failure was a linting failure then can make a command to autofix). Yeah could make a commit and if the diff is good keep it in the PR.

[bnjmnt4n]

This is a pretty common idea actually. Various projects make use of their CI for a build step in order to ensure builds are updated properly. For example, the HTML5 Boilerplate has a Travis script that will build it after every change. In fact, @alrra has made a few easy to use scripts to allow branches to be updated (if necessary) from Travis: https://github.com/alrra/travis-scripts.

[jlongster]

Great minds! I think there are three workflows people can choose from:

1. Use lint-staged to run the formatter check as a precommit hook and will fail if anything isn't formatted (the user then runs a command to format all of them). lint-staged is a lot better than running the formatter across an entire project because it'll be a lot faster: just runs it on changed files. (disclaimer: I haven't looked at that project yet but it seems promising)
2. Have CI check if entire project is formatted and fail if not
3. Do what you described above, and "autofix" it afterwards!

I think #3 is a really cool idea. We basically need a "last resort" option to make sure everything is formatted. Ideally, a github bot could automatically check PRs and if it detects something isn't formatted it could offer to do a follow-up commit or something like that. I like PRs being completely finished before actually pulling the merge button, and that would give you the chance to squash the format PR in with the others. Can github bots add commits to PRs?

[hzoo]

Can github bots add commits to PRs?

Since maintainers can edit other people's PRs now via https://github.com/blog/2247-improving-collaboration-with-forks

then I think it should be possible if the bot is a collaborator?

[suancarloj]

Could it not be just a simple precommit hook that check the staged files ?

[vjeux]

While you could do some pre-commit hook or changing the pull request, it's likely going to be annoying as you are going to change someone else branch, generate merge conflicts...

I think the safest approach is to look at master and append a commit that pretty prints whatever files were touched.

[clarkbw]

Can github bots add commits to PRs?

We are using pushing changes from CircleCI back to GreenKeeper PRs because we are using yarn and want the yarn.lock file updated. See firefox-devtools/debugger#1740 You need to give a r/w key to the CI to allow for the CI to push changes back to the repo. Assuming people always pull down changes before continuing work on PRs this could be an option for you. Here's the script that runs in CircleCI after successful tests.

[kassens]

I found this but haven't tried it myself yet: https://github.com/GordyD/prettier-master

[vjeux]

@GordyD came up with the idea, he started it before going to parental leave. Not sure what's the current status is.

[vjeux]

Let's close this as we're not going to actively work on it, I still believe it would be great to have though!