Previously, I outlined things to consider when picking a starter kit. This post goes into what I do after making a selection.
Introduction
Now that I picked a starter kit (in this case, NextJS's with-typescript-eslint-jest
), as much as I want to start actually building something, I want to lay some foundation first. Of course, I'll build it first to make sure it works! In my case, yarn && yarn dev
is enough to make sure it's working as expected. Other frameworks and libraries may have other commands, and npm
may be used in place of yarn
.
Once I know it's working, I'll do a few things to modernize the project and enforce consistency and code safety in the future:
- Update dependencies
- Configure ESLint, Prettier, and TypeScript
- Rebuild and run tests
- Commit and push
- Set up the IDE
Taking these steps will introduce consistency and safety which will help avoid bugs and friction in the future.
Please read on for details on each of these steps!
Update dependencies
Once I knew it was working, I jumped back into the package.json
file. This time in my IDE, rather than the repository linked above. As I noted in my previous post, a few dependencies were a bit out of date so I updated them to use the latest and greatest.
yarn upgrade
will update packages depending on how they are required in your package.json
. Typically, a caret (^
) is used to avoid breaking changes (i.e. major versions will not be updated) when updating dependencies (a ~
can be used to only pick up "patch" changes, usually bug fixes). Therefore, dependencies bundled with your application may be minor or patch versions ahead of what your package.json
file says.
Since this is a fresh project, I want to pick up major changes too, since breaking changes are unlikely to affect anything or will be easy to resolve. My preferred IDE, WebStorm has a hotkey (ctrl + space) to find and include latest dependencies:
The WebStorm documentation has an explanation:
Code completion for previous package versions. When you press ⌃Space or start typing a version different from the latest one, WebStorm displays a suggestion list with all the previous versions of the package.
Visual Studio Code has a plugin, Version Lens, that displays the latest version and lets you update your package.json
with a click:
In my case, most packages already used the most recent major versions so it wasn't likely that these updates caused any problems. I ran yarn dev
to quickly make sure.
Configurations
I purposefully picked a starter kit that has some extra devDependencies
included, such as Prettier, Jest, and ESLint, but they might not align with my preferences or needs. Before I decide on architecture or start writing new code, I want to configure these settings. Now that I have the most recent versions of my dependencies, I might also be able to leverage some new features that weren't available before.
ESLint
In the .eslintrc.json
, I replaced 0
s with "off"
s and 2
s with "error"
s because I like the explicitness. The "extends"
array, which uses preset recommendations, sets a good baseline, and customizations are up to personal preference. I make a few customizations to make linting a little stricter, like setting @typescript-eslint/no-explicit-any
to "warn"
. Other rules I leave off because TypeScript and Prettier remove the need for them (such as react/prop-types
and @typescript-eslint/indent
, respectively).
The "extends"
list has a note about Prettier:
// Uncomment the following lines to enable eslint-config-prettier
// Is not enabled right now to avoid issues with the Next.js repo
"prettier",
"prettier/@typescript-eslint"
This is straightforward enough, so I do that, and then move on to the .prettierrc
configuration.
Prettier
Prettier is an opinionated code formatter to stop all the on-going debates over styles.. The .prettierrc
file allows you to define a few options such as spaces or tabs (a hottly debated topic!) and whether or not to omit semicolons, or trailing commas.
I'm not going to go into details about what rules I set; the specific rules aren't as important as having the code style consistency that Prettier provides.
I ran this starter kit's format
script to reformat my files with my new settings.
TypeScript
TypeScript, an extension of JavaScript that adds type safety, has an optional configuration file, tsconfig.json
. The file included in with-typescript-eslint-jest
has some preset options. I set "strict"
to true
to turn on "strict mode" which will add some additional safety to my codebase. strict
is a combination of other TypeScript options: noImplicitAny
, noImplicitThis
, alwaysStrict
, strictBindCallApply
, strictNullChecks
, strictFunctionTypes
and strictPropertyInitialization
. Setting the strict
option will tell TypeScript to be more strict around null
and undefined
(strictNullChecks
) and will prevent code from remaining un-typed (noImplicitAny
), among other things.
Other Configurations
There are other configurations that you might want to create or update, such as jest.config.js
(for unit tests) or next.config.js
(for Next.JS), but since those are related to your specific application, that's not necessary this early on. Another benefit of starting with a starter kit is that they will be set up properly.
Rebuild and Run Tests
Once my dependencies are up to date and configurations are done, I ran yarn dev
to make sure there were not regressions. I also ran yarn test
for good measure, and discovered that a test failed because a snapshot was not updated, so I had a great opportunity to fix it by opening a pull request!
Commit and push
If using git
, running the commit
and push
commands at this point will bring up potential issues with version control such as permissions and making sure the repository actually exists and some quality checks may also run, facilitated by git hooks). Running these git
commands will also show whether or not they are set up and working properly.
Auto-formatting and linting scripts are often set up as a pre-commit scripts. Both of these actions are usually quick since they can run on individual files and are not concerned with the rest of the code.
TypeScript compilation typically takes longer, and depending on your workflow can be frustrating to run as a "pre-commit" check. As a "pre-push" check, it will make sure that other people working on the same code aren't picking up code that doesn't compile!
pre-commit
and pre-push
quality gates (as well as others) can be customized to your, or the team's, needs.
In my case, with-typescript-eslint-jest
was already set up with Prettier and ESLint to format and lint changed files as a pre-commit
hook, and TypeScript compilation was included as a pre-push
hook.
IDE Setup
Now that my application has the configurations I want and I know they work, I'll set up my IDE to hook into them. With WebStorm, a lot of these settings are done in the Preferences panel. Searching for Prettier, for example, allows you to automatically pick up the .prettierrc
settings (I also like to enable "Run on save"). There are similar options for ESLint and TypeScript, which may be configured automatically.
Visual Studio Code's extensive extension collection covers these features as well: Prettier - Code Formatter and ESLint plugins can be installed and configured as needed and have their own extensive documentation and examples.
Summary
I haven't really built anything quite yet but I know that when I do, future errors will be caught sooner than later since now I have a few places where errors are surfaced: my IDE, before code is committed, and before code is pushed (and likely shared). These automated tools won't find all errors, but the ones they do find are the most common, easiest to fix, and can be underlying errors that cause real bugs.
Setting up Prettier will help me focus on what I'm building. On a team, introducing automated formatting in the workflow will reduce the time code changes spend in code reviews, and will keep the code consistent.
Doing this now, before I've actually written any code, will save me headaches in the future.
Top comments (0)