This lesson preview is part of the The newline Guide to Building a Company Component Library course and can be unlocked immediately with a \newline Pro subscription or a single-time purchase. Already have access to this course? Log in here.
Get unlimited access to The newline Guide to Building a Company Component Library, plus 70+ \newline books, guides and courses with the \newline Pro subscription.
[00:00 - 00:11] Enforcing consistent patterns in syntax is an important part of maintaining a component library. Code Linting tools help enforce consistent code formatting and ensure that important code quality rules are being followed.
[00:12 - 00:19] In this lesson, we will be adding prettier and theest length to our codebase. Pertier is a code format with support for most types of files.
[00:20 - 00:30] It focuses on ensuring that our codebase file is consistent formatting rules like max line length and consistent comma usage. Let's install that with npm install.
[00:31 - 00:38] Save dev prettier. And this is a development dependency because it isn't necessary for it to run in production.
[00:39 - 00:46] Pertier comes with an impinginated set of default style rules. But for our library, let's create a prettier RC file.
[00:47 - 00:57] And we can override the single quote. So that way it's enforced across our codebase.
[00:58 - 01:03] So now let's go into our package.json. And we're going to modify this to include two new scripts.
[01:04 - 01:10] Let's start with format, which will run prettier. Right.
[01:11 - 01:23] And then let's also add in a lint step so we can make sure that our files are enforced by prettier as well. So we can run prettier check for that.
[01:24 - 01:36] So if we were to run format, npm run format, we should see all of our files updated to use the new prettier syntax. Nice.
[01:37 - 01:43] And then we can run npm run lint format just to double check that everything is passing correctly. Cool.
[01:44 - 01:57] And so we can see in our diff here, we can see main JS and everything else has been formatted to match our pretty good config. Next, let's go ahead and add in ESLint.
[01:58 - 02:13] So ESLint is a static analysis tool that allows us to ensure that our code falls specific code quality rules by including additional ESLint plugins were able to reduce potential react and type script bugs. So prettier is mostly focused on code style while ESLint.
[02:14 - 02:22] It does handle that somewhat, but it's mostly focused on code quality more than the individual style. So we're going to be using several plugins here.
[02:23 - 02:35] And let's go and copy this over. And while this is installing, we can run through them. So we're going to be using type script ESLint, both the parser and the ESLint plugin to allow ESLint to understand our type script files as well as JavaScript.
[02:36 - 02:43] We're going to be using the config prettier plugin that allows us to reference our prettier rules. So ESLint prettier don't fight each other.
[02:44 - 03:03] And then we're going to be including the react and react hooks plugin, which allows us to enforce some react specific rule sets. And then let's create a new ESLint RC file.
[03:04 - 03:13] And this is just an opinionated default rule for us to start with. This is a root config that is using the TypeScript ESLint parser to parse the files.
[03:14 - 03:23] We're going to be using some, most of the recommended rule sets for all of our plugins. And then for the react plugin, we're going to let it detect the current react version from our package.json.
[03:24 - 03:33] One customized rule that we have here is react prop type. And once we're writing our components in TypeScript, this is going to be a little confusing to start out with.
[03:34 - 03:47] So we're going to disable it for now, but we'll be using this rule set later on . And then enter package.json. Let's add in a new script called lint.
[03:48 - 03:53] And we'll call it ESLint source. So it lends everything within our source directory only.
[03:54 - 04:01] So if we run npm run lint here, we're actually going to get an error. Nice or a warning.
[04:02 - 04:11] So our button.tsx file is missing a return type by default. So we can fix that by directly referencing react.function component.
[04:12 - 04:16] And so now that is the explicit return type for button. And that should fix our problem.
[04:17 - 04:25] Nice. So VS code has some pretty good integrations with prettier and ESLint.
[04:26 - 04:30] I've included the links to them in the docs. So if you don't have that set up yet, go ahead and add it in.
[04:31 - 04:45] But there's some really interesting helpers where you can actually disable rules or automatically fix things if it's possible to do so with the rule set. So now that we have ESLint and prettier added in, let's go ahead and commit our changes and save our progress.
[04:46 - 05:14] And in the next module, we will learn some common shared component patterns and styling solutions by creating a new button component. [ Pause ]