DEV Community: Daniel Bernardino

Good configs for Typescript

Daniel Bernardino — Tue, 24 Jan 2023 15:10:48 +0000

I'm not a professional in this technology, but I understood the importance that a setup has in our applications. I'll show my back-end setup and I hope you like it.

For didactic purposes, I'm going to install some dependencies that don't necessarily have to do with one another. Imagine that it is your application will not deviate much from this pattern.

Thinking about making this article applicable, and you don't have to look for the configurations in the middle of the explanations I'll leave it as a step-by-step, and at the end, explain everything, feel free to read it as you wish.

npm init -y

npm i cors dotenv express pg morgan

npm i -D nodemon typescript ts-node

npm i -D @types/express @types/node @types/cors @types/pg

npx tsc --init

./tsconfig.json

{
  "compilerOptions": {
    "target": "es2021",
    "module": "commonjs",
    "rootDir": "./src",
    "esModuleInterop": true,
    "outDir": "./dist",
    "moduleResolution": "node",
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "skipLibCheck": true,
    "allowSyntheticDefaultImports": true
  }
}

// commit
chore: add basic configs and ts config

./package.json

"script": {
  "start:dev": "nodemon --watch 'src/' --exec 'ts-node src/server.ts' -e ts",
  // ...
},

// commit
chore: add ts-node and nodemon setup

npm i -D eslint prettier eslint-config-prettier


npm init @eslint/config

.eslintignore

node_modules
/*.js

.eslintrc.json

{
  "env": {
    "browser": true,
    "es2020": true,
    "node": true
  },
  "extends": [
    "plugin:@typescript-eslint/recommended"
  ],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaVersion": "latest",
    "sourceType": "module",
        "project": ["./tsconfig.json"],
  },
  "plugins": ["@typescript-eslint"],
  "rules": {
    "space-before-function-paren": "off",
    "@typescript-eslint/no-empty-interface": "off"
  }
}

.prettierrc.json

{
  "semi": false,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "all",
  "printWidth": 120
}

//commit
chore: add eslint and prettier setup

npm i -D husky lint-staged git-commit-msg-linter

.package.json

"scripts": {
  "husky": "husky install",
  //...
}

.lintstagedrc.json

{
  "*.ts": [
    "npx eslint 'src/**' --fix",
    "npx prettier --check 'src/**'"
  ]
}

npm run husky

npx husky add .husky/pre-commit "npx lint-staged"

npx husky add .husky/commit-msg ".git/hooks/commit-msg \$1"

// commit
chore: add husky and lint-staged setup

npm i -D tsconfig-paths tsc-alias

.package.json

"script": {
  "build": "tsc && tsc-alias",
  "start:dev": "nodemon --watch 'src/' --exec 'ts-node -r tsconfig-paths/register src/server.ts' -e ts",
  //...
}

./tsconfig.json
{
  "compilerOptions: {
    // ...

    "paths": {
      "@/*": ["*"]
    },
    "baseUrl": "./src"
  }
}

// commit

chore: add tsconfig-paths to script dev and tsc-alias setup

First of all

Start your application and install the basic dependencies, checking if their respective types exist, if in doubt, try installing it with @types/<name-lib>.

All ready, basic dependencies of a back-end application using Express, Typescript and postgreSQL.

Now we need to initialize the Typescript, remembering that it is a tool that will 'modify' your file, adding a layer of processes and typing that will not go to production.

A tsconfig.json file will be created, where you can add and configure your Typescript.

All properties have some value, and I recommend that you research or even test the change that each of them may have in your project, but the ones described in the step-by-step were the ones that best suited my style of code.

Some interesting ones to mention:

"allowSyntheticDefaultImports": this way will be able to do default imports, like import express from 'express';
"skipLibCheck": this can save time during compilation at the expense of type-system accuracy.

IT'S IS IMPORTANT

I see many junior developers who don't understand scripts and how they work, this is worrying, because they are an details of your application that needs to make sense with its context.

Let's understand our script:

"start:dev": "nodemon --watch 'src/' --exec 'ts-node -r tsconfig-paths/register resrc/server.ts' -e ts"

Uses nodemon to monitor changes to files inside the "src/" folder
Run ts-node to record the tsconfig path, and run the server.ts file inside the "src/server.ts" folder
Uses the .ts extension for TypeScript files.

Explaining a little better:
I want this application to have the 'start:dev' command in which to run the nodemon lib and watch (--watch) just the "src/" folder and then run the 'ts-node -r tsconfig-paths/register resrc' command /server.ts', in this command I want to run ts-node to build my application and start it with my main file 'server.ts'

Continuing,

I'm not going to explain the configuration of eslint and prettier, it's something personal, and normally in a company everything is already configured for you, but study to better understand how you can do it your way.

The gits hooks are very valid for N reasons, but the configuration I left is specific to code standardization it if you work with a team, having a standardized code is very important. Of course, issues like programming logic are not so simple to standardize, but this configuration will help with formatting and semantic commits.

Lastly,

We have path mappings, beautiful and smelling it's solve the paths like '../../../../../BlaEntity/index.ts'.

I will demonstrate following the example above:

.tsconfig.json

"paths": {
   "@Bla/*": ["/domain/entities/flo/flu/BlaEntity/*"]
},
"baseUrl": "./src"


./another-file

import { BlaEntity } from '@Bla/index.ts'

It's a silly example, but feel free to define the nomenclature you want, then just assign its value with the path you determine.

Thank you for reading, I will try to make better and smaller articles, but I confess that I get carried away writing <3

ESLint in 2022, from a beginner's point of view ;)

Daniel Bernardino — Sat, 29 Oct 2022 14:32:49 +0000

Hey, there. In quick work, it's important to say that I'm a beginner dev and this is my first post, and maybe I have a little "naive" view of Linters. In that case, I hope for your help in the comments. Let's get to the point.

Installation

If you know a little about package managers, any installation will be easy, look in the eslint documentation.

Anyway, I'll leave below the list of commands for you to do this, but try the documentation, because it can update, well, anytime.

First of all,

We are in a situation where, in your code editor (I'm using vscode), you don't have any extensions or settings already changed by you to use linters. Please pay attention to this.

And you need to start your project, It could be an npm init, it could be npm init -y, it could be a create-react-app, vite, it doesn't matter so much.

Start it however you feel comfortable.

Now yes, install eslint

npm init @eslint/config

This command will already create a .eslintrc folder (where you configure eslint) and will ask you some questions. You're free to answer each one because it depends on your type of project and your desire as well.

I choose these options:

? How would you like to use ESLint? … 
  To check syntax only
  To check syntax and find problems
▸ To check syntax, find problems, and enforce code style

Choosing a code style already gives you a set of rules that a lot of people use, in all cases, it's good to use.

Next question.

? What type of modules does your project use? … 
▸ JavaScript modules (import/export)
  CommonJS (require/exports)
  None of these

Understand this part as the way you import and export things. requise are already going out of fashion, so to speak, usually, your choice will be the first option.

Next.

? Which framework does your project use? … 
▸ React
  Vue.js
  None of these

? Does your project use TypeScript? ‣ No / Yes

I'm using React and in this project, there's no need to apply Typescript

We're just starting!

? Where does your code run? …  (Press <space> to select, <a> to toggle all, <i> to invert selection)
✔ Browser
✔ Node

Normally you will leave both options checked, but feel free to choose where your code will run.

Next!

? How would you like to define a style for your project? … 
▸ Use a popular style guide
  Answer questions about your style

? Which style guide do you want to follow? … 
▸ Airbnb: https://github.com/airbnb/javascript
  Standard: https://github.com/standard/standard
  Google: https://github.com/google/eslint-config-google
  XO: https://github.com/xojs/eslint-config-xo

I chose Airbnb to demo and it's also the one I use the most, but feel free to inquire about other famous style guides

More one!

? What format do you want your config file to be in? … 
  JavaScript
  YAML
▸ JSON

I like to use JSON format because normally the other settings, by default, come in JSON. The difference between them is very little.

Next question!

? Would you like to install them now? ‣ No / Yes

? Which package manager do you want to use? … 
▸ npm
  yarn
  pnpm

I don't know what happens if you don't install it now, you might have to do it all over again, but anyway, if we started all this to install, let's go all the way. I use NPM as a package manager.

Finally, it's over... just kidding,

This is the part we do in the terminal, now you can open your file, and I'll use the code . command to open my code editor.

In your code editor,

Now, you have installed your first linter. Congratulations!!!
Let's take a look at your editor, it'll look like this:

The most important parts you need to understand in eslint settings are extends, plugins, and rules.

Extends:

Roughly speaking, Extends are files full of rules already configured. Downloading one you like and adding it to the array, it's ready to use.

Nothing prevents you from installing several extends, but there is an important detail that will define the conflicts that your file may have.

If you add your extends outside the array, they might conflict, because that means you're applying the two entire extends to your file.

Your code editor will warn you that this is impossible to do, semantic errors of an object. That's why you should put it inside an array if you're using more than one extension.

Inside an array, your extends will inherit the characteristics of the previous extends.

For example, looking at the image above, I can say that if there is an equal rule between the two extensions, the Airbnb rule will prevail.

If I added another extends and it also had conflict then this one would take priority.

The order of priority is descending: from the last item in the array, to the first.

Plugins:

Plugins are different, they are like a file that you install and leave in your project. It won't do anything until you give the command.

It will make your rules available for you to use.

The extends apply them the moment you add them, the plugins, even adding, don't apply your rules, just make them available for you to use.

Rules:

Now I'm going to create an index.js and make my first React component, let's see if our linter is working. To do this I will go to the terminal and put an npx eslint .

const MyComponent = () => {
  return (
    <div>
      <h1>Hello, dev.to</h1>
      <p>Please like this post!!!</p>
    </div>
  )
}

export default MyComponent;

Wow, I thought that everything was ready, it seems that there are a lot of mistakes here and some very important ones.

In my case, my first mistake is to use React, without even installing it in my application, what a big mistake. But there are also some minor bugs like the lack of semicolons.

My Airbnb extends is telling me all these errors, I can change it if I want by changing the rule value. The basic values that exist are: error, warn, off;

The rule can be considered an error, a warning, or it can be disabled.

Let's disable the semicolon problem and also the newline that was reported by eslint;

Notice that at least now those silly errors are no longer being warned.

And that's how rules work, you can write rule changes however you want, even applying an extends or plugin. We have other errors being shown but will be explained later.

Last but not least

Now you understand how your linter extends work, how you can use plugins, and also how to see your errors.

But let's make it easier.

As I am using vscode, I will install the ESLint Extension, click on the configuration option, and click on add to Workspace recommendation. Doing so will create a folder called .vscode with a file inside about the extension you just recommended.

This means that every time someone downloads your project, vscode will recommend that they install this extension. It's practical, isn't it?

Now your errors will be indicated by vscode itself, there is no need to run the command npx eslint .

Bonus

ESlint also gives you the option to fix these errors, if you noticed the terminal errors, it suggests that we use the --fix command.

To do this you need to have your files saved and run the command:

npx eslint . --fix

The simplest errors will format themselves, but some will persist and you must pay attention to them.

Formatting when saving

Remember when vscode created a .vscode folder?

We can use this same folder to define the vscode settings in the project.

This means that these settings won't change other projects and if someone downloads it, they won't need to change any settings in their code editor.

Create a file called settings.json and add the following code to it:

{
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  }
}

You will be telling your vscode:
When you save a file, use eslint to format errors;

In this case, you will be using your ESLint, not only as a Linter but as a Formatter.

I'll leave this topic of formatters for another post. But it is important that you understand the processes I mentioned and how you have the freedom to use them however you want.

That was it for today, I hope you enjoyed reading and that you tried to practice.

See you later.