combine-prs-workflow VS demos-nuxt

To address inefficiency caused by separate PRs, a workflow was designed to join them automatically into one big PR. However, it was unable to deal with lockfile conflicts. PRs that caused conflict in the Combine PRs job, were omitted and you had to add them manually anyway. It spared some time, but the developer experience was still far from being perfect.

Another pitfall I ran into recently with a workflow I've been working on [1]: Checks and CI that are made with GitHub Actions are reported to the new Checks API, while some (all?) external services report to their old Statuses API. This makes it needlessly difficult to ascertain whether a PR/branch is "green" or not. They finally decided to create a "statusRollUp" that combines the state of the two APIs, but it's not available in their REST api, only their GraphQL API.

[1] https://github.com/hrvey/combine-prs-workflow/

GitHub Actions can do some neat things. I got tired of waiting for Dependabot (tool that makes automatic PRs to update your middleware, acquired by GitHub) to add an option to group PRs together (it opens a separate PR for each dependency that can be updated, so merging and re-running CI can take a long time) so I scratched my own itch and made a workflow that merges their PRs together: https://github.com/hrvey/combine-prs-workflow Been running it for a year now, and still pretty happy with it.

Parameter directory locates your package.json (or respective file with dependency definitions). In this case we assume that it is preset directly in the root. But for example, in a project at my work we have the JS application wrapped inside a Docker container, so the value would have to be /app. Or you could have a monorepo with multiple sub-projects. Then you need to set Dependabot separately for each. Here ïs an example.

Starting a new project with Nuxt is very simple. In fact, technically all you need are just two files. However, for the begining you should rather follow the Nuxt official recommendations. Or, if you like to, you may also use my own Nuxt Starter project which is already prepared and a bit enhanced with eslint, which I find invaluable in terms of code maintenance. To start benefiting from eslint’s static code analysis, you need to install an extension into VS Code.