Tag: linting

Maintaining an ESLint config has several benefits, a significant one being seeing new rules as they become available. ESLint shapes the way we use JavaScript, and now TypeScript too. As I prepared for the latest release of my own ESLint config, I became aware of several new and helpful rules for testing with Jest. In this post, I'll dive into what some of these new rules are and some considerations for why they aren't added to the options. The interesting balance of ESLint semver ESLint rules are an interesting interplay with semantic versioning or semver. Adding a new rule as an option is considered a feature and warrants bumping the package a minor version. However, enabling the rule as an error can cause new lint errors. This is…

I have used ESLint for a long time, often extending the recommended rules from various plugins. I only read a rule’s documentation if I wasn’t sure why it was being flagged in the linter. Last month I read through and manually set 381 ESLint rules, reading the accompanying docs for each rule. I discovered that ESLint is more than enforcing community guidelines on code quality. It also helps to shape use of the language as a whole and through project specific rule usage. Greater control for team objectives There are a number of rules the recommended configurations of ESLint or various plugins do not enable by default. These rules serve specific needs of a given project. They can be enabled and configured on a per project basis and provide…

Jest Snapshots can be a valuable utility for monitoring code changes for UI components. They can also become a scourge if they become too large. The line between the two isn't always clear. Snapshots don't offer a clear mechanism to determining how large they are. This makes it easy to create large snapshots that are hard to diff. The likelihood of a thorough review on a snapshot diff decreases in relation to the size of the snapshot. I have both observed and committed broken snapshot updates into repositories as part of a branch. The danger lies in making intentional changes to a particular feature and updating the snapshot without checking for other breakages. If the snapshot diff is large, it will likely not receive as thorough a review…