Getting Started with NodeCG: Cleaning up the Environment

Last time I talked about getting Parcel and some other tools set-up so that we can get started developing widgets with NodeCG. I’m not going to cover NodeCG widgets quite yet, but if you want to learn how you can keep your brand new development environment in a clean state… then I’ve got you covered today!

As I mentioned last time, you can see me apply these steps in order in this GitHub repository.

Alright, let’s get started! 😁

Catching code and format smells with ESLint + Prettier

Our dev environment is setup—why go further? Well, sometimes we write code that is innocuous now but could be problematic in the future, or we might have other people working with us and it’s useful to have a consistent style or format.

• ESLint can help us with part of this. We can use it to find and fix JavaScript (or in our case, TypeScript) problems
• Prettier is an opinionated code formatter so that we don’t have to think about how we format our code

Let’s set those up!

ESLint

Installing ESLint is straightforward, but depends a lot on how you want to configure it. All you need to do is npm install --save-dev eslint then npx eslint --init to go through the wizard. I opted to pick the standard JS style but there are other styles available.

If you run eslint now (npx eslint "src/**"), it may warn you about some potential problems in the code we’ve written (oh no!). Some of these problems are self-imposed, but others might feel unfixable, for example:

React must be in scope.

h is defined but never used.

How do we handle these?! 😲

While our bundling process is aware of these variables, eslint is not. To fix this, we’re going to npm install --save-dev eslint-config-standard-preact¹ and make a small changes to our .eslintrc file.

"extends": [
    "plugin:react/recommended",
    "standard",
    "standard-preact"          // No need to add prefix; eslint is smart like that
],

…And if you run eslint again, the errors should hopefully go away. If they don’t, it’s possible that we missed something. Hopefully there’s enough information to resolve the issues if so 🤞

Prettier

That leaves Prettier. Honestly, if it’s just one person working on the project, adding this might be a bit of overkill, but it’s easy to add and leaves code in a consistent style so I’d still recommend it (and it works for multiple different file types).

Installation is pretty easy, and once you’ve done that, you can run npx prettier --write . to format all support files in your project!

…But don’t do that just yet! Prettier and ESLint may not agree on formatting—running Prettier could create style-based linting errors 😱

So we’ll need to fix that! Fortunately, Prettier has some documentation on a few different ways you can resolve this depending on your setup. In our case, we can go the recommended route and npm install --save-dev eslint-config-prettier and add it to the end of our .eslintrc “extends” as before:

"extends": [
    "plugin:react/recommended",
    "standard",
    "standard-preact",
    "prettier"                 // Again, no prefix necessary
],

More details on the eslint-config-prettier plugin are here. It will disable several rules but that’s worth it to make sure that the two programs don’t fight.

And voila, we’ve made our environment a little bit cleaner! ✨

…But can we do more? 🤔💭

Optional: Integrating with Atom

It’s great that we have these tools, but running them manually still kind of sucks. Manual tools are tools that are not run very often.

There are a few different ways to fix this.

• Git hooks: automatically run our tools before committing. Prettier even has some documentation on a few different ways of doing this including a tool called Husky which is intended to make git hooks easier.
• Automatically run tools in your IDE: As long as you aren’t running notepad, you can probably set this up
• Build toolkits (e.g. Gulp, Grunt, possibly even webpack or Parcel, CI): Have the tools run as part of the build process!

Heck, you can probably implement a bunch of these simultaneously—which also reduces the likelihood of it being missed—but we’re going to focus on setting it up in the IDE for now. 🔍

I use Atom, so most of the following steps will be specific to it, but I’m sure similar plugins or settings are available in most IDEs.

A quick rundown of the packages I installed, and the settings I had to change:

• linter: This allows any sort of linting in the Atom UI. However, it needs specific linters installed to work…
• linter-eslint: Allows us to use eslint with linter! Atom will look for a version of eslint in the project, and if it can’t find one, will use a version that it is prepackeged with.
  • By default, it doesn’t know to lint .ts and .tsx files. To fix that, you’ll need to go into Atom’s settings > Packages > linter-eslint, and under it’s settings add source.ts, source.tsx to the list of scopes.
• prettier-atom: Surprise! This will allow Atom to run Prettier.
  • Most settings you can leave as is, but I’d strongly suggest setting it to “Format on save” and also “Only format if a Prettier config is found”. This avoids the issue of formatting other files in Atom unexpectedly for projects not using Prettier.
• atom-typescript: This lets Atom know about Typescript files so it can syntax highlight correctly and provide other useful typing hints

There’s also one last one which is super unnecessary for an individual project, but I’m including for completeness because I think it’s a cool idea to avoid arguments in groups: EditorConfig. 🤓

In a nutshell, EditorConfig is another way of maintaining consistent code styles, but instead of doing it after the fact, like Prettier, it does so while you’re coding. It’s mostly for things like indentation amounts and type (tabs vs spaces), character sets, and line endings. It’s a little less necessary since we’re using Prettier, but a useful tool to add to your toolkit (and is supported by many IDEs).

To get it to work in Atom, we just need to install editorconfig and add a basic file to our project at the root. I picked these settings fairly arbitrarily based on my preferences:

[*]
end_of_line = lf
charset = utf-8
indent_style = space
indent_size = 2
max_line_length = 80

And that’s it! We now have a really tidy setup for our NodeCG development! I hope it won’t be too long before I can talk more about how to actually develop widgets, but I wanted to show you all how you can set things up cleanly for… well, most front end projects! 🥳