DEV Community: Jake Patterson

Practising Git hygiene with fixup commits

Jake Patterson — Sun, 04 Feb 2024 12:01:35 +0000

Git takes a long time to become comfortable with. Still now, years after I first used it, I hold my breath doing rebases and cross my fingers there are no conflicts. It is not controversial to say Git is unintuitive, with strangely named commands and a lacking command line interface. Unfortunately, we're stuck with it for the time being...

"Git hygiene" refers to good organisation of a Git repository and its commit history. Commits act as documentation and are often used to generate release notes, so it is important they describe changes accurately. For me, each commit should represent the project in a working state. I should be able to checkout something from a couple weeks ago and run the project without error. That said, it is common to see the following in pull requests:

feat(Button): add size variant
chore: fix linting
fix: pull request feedback
fix: failing test

There are a few problems with the above:

Too many commits. In the context of a PR the commits are useful. The reviewer can understand how and why the branch is changing. Outside of the pull request, though, that information is not useful. Typically, developers will squash commits to address this problem, ensuring the final commit message is appropriate. In itself that presents further problems:
- What if we want multiple final commits in a pull request? We may have a larger pull requests, with logically separated commits, each of them able to be individually reverted.
- What if the commits themselves are under scrutiny by the code reviewer and/or automation?
If I checkout the first commit linting and tests will fail. Not a problem if the commits are squashed, but if they aren't, our main branch is polluted with broken commits. Later on, identifying which commit introduced an issue becomes harder.
With each round of code review further changes will need new commits, likely meaning the commit messages get sloppier and less legible. Following something like Conventional Commits is wasted cognitive load when we know we are squashing the commits anyway.

Fixup commits offer us an alternative here. Let's start with the commit:

feat(Button): add size variant

Imagine I open the pull request and an automated workflow tells me there are lint issues. Instead of naming a new commit I can run:

git commit --fixup [COMMIT_SHA]

Which results in:

feat(Button): add size variant
fixup! feat(Button): add size variant

When I first saw that I thought it was perfect. It indicates exactly my intentions to the the reader: I want one commit, but I am "fixing" it with further revisions. Now, we could rebase locally and push only a single commit back to the remote branch, but in my experience GitHub doesn't like that. In the case of some feedback being addressed I want to compare the previous state to the new one and I need multiple commits for that.

Still, we do need to squash the commits before merging since we don't want them ending up on main. Thankfully, we can do:

git rebase main -i --autosquash

This applies all the fixup commits, resulting in one (or more) clean and hygienic commits that are ready to be merged. I do wish GitHub would integrate this functionality into its user interface. Currently that command must be run locally, instead of using the "Rebase and merge" button.

Who manages the package managers?

Jake Patterson — Sat, 27 Jan 2024 12:13:10 +0000

The JavaScript ecosystem is notorious for moving quickly. Just a few years ago Yarn (now Yarn Classic) was ubiquitous. Since then, 3 major yarn versions have been released and new competitors have entered the market. While upgrade paths can be straight forward—with pnpm even providing pnpm upgrade—the problem of managing package managers arises.

Consider an organisation with hundreds of JavaScript repositiories. Some have long been abandoned and others have an active development team keen to use the best-in-class tooling. Maybe at a glance it is obvious which flavour of package manager a repository depends on; we may see a package-lock.json or yarn.lock file. However, further inspection is needed to determine which version of NPM or Yarn created those. It is too easy for a developer to end up recreating a lock file after running the wrong command. Not a great experience!

A better approach is to use a combination of the following tools. Firstly, fnm (Fast Node Manager) is a well established Node version manager. After setting up your shell environment, navigating to a project folder is all that is required to detect and switch to the correct Node version, provided a .node-version file exists. We can take this a step further by adding packageManager to our package.json:

+ "packageManager": "pnpm@8.14.3"

On its own that isn't going to do much. A developer would still need to open package.json to find the correct package manager to download. We can automate that with Corepack. Corepack is an experimental feature of Node that looks for the packageManager field and silently downloads the version when running scripts. It also throws an error if the wrong package manager is used in the scope of the project. It is an opt-in feature though, so corepack enable must be run after Node is installed. Alternatively, fnm can be configured to do that automatically:

- eval "$(fnm env --use-on-cd)"
+ eval "$(fnm env --use-on-cd --corepack-enabled)"

Now, running any package manager command comes with a guarantee; with the above configuration, pnpm -v always resolves to 8.14.3 and yarn -v errors. Note that package managers previously installed globally should be uninstalled first. Without doing that, we won't see the wonderful error:

Usage Error: This project is configured to use pnpm

4 ways to improve type checking in Vue components

Jake Patterson — Thu, 31 Dec 2020 01:49:11 +0000

TypeScript is increasingly becoming a go-to when starting new projects. It has proven to catch pesky bugs arising from loosely typed code and ease the refactoring of larger codebases. For that we are eternally grateful 🙌.

However, when it comes to using TypeScript with Vue there are some pain points. The main culprit being Single File Components, which do not come under full scrutiny by the TypeScript compiler. Type errors within a <template> tag are not detected and can slip through into a production environment. Component property violations, for example, are only detected at run time.

Here I will outline 4 methods to ensure 100% of your Vue component is type checked.

1. Vue JSX Factory

The first two recommendations ditch Single File Components in favour of JSX.

Ultimately .vue files are a proprietary syntax known only by Vue and other community maintained projects. JSX is not a standard either, but in the world of TypeScript is can be considered as such. We can take advantage of that!

Vue JSX Factory is the only method where by we can directly use tsc (or esbuild) to compile our code. Babel is an optional enhancement - not a requirement - and so our project setup is very lightweight. In fact, the only necessary package is vue-jsx-factory. After updating tsconfig.json to the following:

{
  "compilerOptions": {
    "jsx": "react",
    "jsxFactory": "j"
  }
}

components can be defined using JSX. Importantly, the j function must be within scope wherever we define components:

// Header.tsx
import { j } from "vue-jsx-factory";
import { defineComponent } from "@vue/composition-api";

export const Header = defineComponent({
  name: "Header",
  props: {
    title: {
      type: String,
      required: true,
    },
  },
  render() {
    return (
      <header>
        <h1>{this.title}</h1>
      </header>
    );
  },
});

You do lose out on some directives (e.g. v-model), although these could enabled at a later date. Going down this route removes a lot of fluffy dependencies, such as Vue Loader or Vue Jest.

2. Babel Preset JSX

JSX can also be written with the aid of a Babel preset. It is officially supported by the Vue core team and has more features than Vue JSX Factory. Presuming Babel is already integrated in your project, just install the packages and update the Babel configuration:

npm install -D @vue/babel-preset-jsx @vue/babel-helper-vue-jsx-merge-props

// babel.config.js

module.exports = {
  presets: ["@vue/babel-preset-jsx"],
};

Thanks to some Babel magic, the render function is automatically imported in to scope, so no need for a manual import in component files.

3. Vetur Terminal Interface (VTI) ⚠

An extension to the famous Vetur VS Code plugin and also available as a command line tool, VTI enables type checking on Single File Components. Unfortunately, it is still marked as unstable, although I am excited to see where it is headed! At the time of writing this article it can run via a single command:

npx vti # at project root

4. TypeCheck for Vue

Last but not least, Vue Developer Experience provides us with TypeCheck, another method for checking Single File Components. Currently it runs as a command alongside your build and, like VTI, is still early days; the first public release being 28th December 2020!

Conclusion

Using Vue together with TypeScript can at times feel premature. Relying on community maintained dependencies to achieve type safety is risky and in an ideal world avoidable. While there is hope with Vue 3 and Vite, it will take some time for the ecosystem to catch up. In the mean time, those using Vue 2 can find an extra layer of assurance with these additional tools.

If you would like to get those benefits early, without fully migrating to Vue 3, the Composition API is already available in Vue 2. defineComponent has massively better type inference than Vue.extend or the Class Component Syntax (soon to be deprecated).

Thanks for reading!