@buildinams/lint

lint

BiA's base lint config(s).

Installation

Install this package with npm.

npm i -D @buildinams/lint

Usage

This package export six base ESLint, one Prettier and one base Stylelint configuration:

• JavaScript (@buildinams/lint/eslint/javascript)
• Typescript (@buildinams/lint/eslint/typescript)
• React.js JavaScript (@buildinams/lint/eslint/react-javascript)
• Next.js JavaScript (@buildinams/lint/eslint/next-javascript)
• React.js TypeScript (@buildinams/lint/eslint/react-typscript)
• Next.js TypeScript (@buildinams/lint/eslint/next-typescript)
• Base Prettier (@buildinams/lint/prettier)
• SCSS with CSS Modules (@buildinams/lint/stylelint)

ESLint

@buildinams/lint/eslint

This is our base config for all React projects. It extends:

• react/recommended
• react-hooks/recommended
• jsx-a11y/recommended
• prettier/recommended

To use the shared eslint configuration, create an .eslintrc.json in your root project directory, and extend the config:

{
	"extends": "./node_modules/@buildinams/lint/eslint/react-javascript"
}

@buildinams/lint/eslint/react-typescript

This extends our base React config with parsing / linting support for TypeScript from @typescript-eslint/recommended.

To use, create a .eslintrc.json and extend the config:

{
	"extends": "./node_modules/@buildinams/lint/eslint/react-typescript"
}

@buildinams/lint/eslint/next

This is our base configuration for all Next.js projects. It extends:

• next
• next/core-web-vitals

To use, create a .eslintrc.json and extend the config:

{
	"extends": "./node_modules/@buildinams/lint/eslint/next-javascript"
}

@buildinams/lint/eslint/next-typescript

This extends our base Next config with parsing / linting support for TypeScript from @typescript-eslint/recommended.

To use, create a .eslintrc.json and extend the config:

{
	"extends": "./node_modules/@buildinams/lint/eslint/next-typescript"
}

Extended ESLint Rules

The idea behind this config is to enforce consistency across all projects. We've tried to keep the rules as minimal as possible, and for the most part simply inherit from the recommended rules of the plugins we use. The main exceptions are when it comes to the following. Note: We've purposely only defined rules that are auto fixable, these rules should make it easier to write code, and not get in the way. With one Typescript exception.

eslint-plugin-unused-imports

This is used to enforce that all imports are used in the file. This is used to prevent unused imports from being committed to the repo.

eslint-plugin-simple-import-sort

This is used to enforce a consistent import order. The following order has been defined:

1. External modules (e.g. react, next and @buildinams/)
2. Absolute imports (supports prefix of _ and ~ e.g. public/, _components and ~/contexts)
3. Relative imports (e.g. ../ and ./)

Note: The biggest thing we enforce here is the use of prefixes (either _ or ~) for absolute imports. This is to make it clear that these are not external modules, and to make it easier to distinguish between the different modules when enforcing the import order.

eslint-plugin-import

This is used to auto fix some common inconsistencies. The following rules have been enabled:

• import/first - Makes sure all imports are at the top of the file.
• import/newline-after-import - Makes sure there’s a newline after the imports.
• import/no-duplicates - Merges import statements from the same file.

@typescript-eslint/consistent-type-definitions

Used to enforce type over interface, the difference between interface and type is minimal and the one additional feature it supports we shouldn't use.

no-restricted-syntax

• TSEnumDeclaration - Error when using Enums, let's push for const Foo as const since it's more declarative that it outputs JS. Enums are in a weird in between state that they are both types and constants. This makes them confusing on how to use them and what the output will be.

Note: The TSEnumDeclaration is our only rule that can't be auto-fixed by Eslint. This is because based on what we need the enum for the 'correct' approach might differ.

Prettier

@buildinams/lint/prettier

Our base prettier setup, it doesn't have any custom plugins at this point but we do modify two rules, explained below.

To use, create a .prettierrc.js in the root of your project and export the config from the package;

module.exports = require("./node_modules/@buildinams/lint/prettier");

Trailing comma; "all"

Keeps the trailing comma around wherever possible. Advantages; less changes in Git when adding a row, more flexible when changing the order of entries in; arrays, objects and function arguments. Alternative value: "es5", we have a compile step so we can write "future" JS in our source code without worries.

Tabs

Tabs over spaces, spaces have a fixed width and tabs can be whatever the developer wants it to be using a custom tabWidth value.

Quotes

We enforce the use of "double quotes" when possible. We defined this with the intent of it being applied as a auto-fixable rule to enforce consistency with prettier.

Stylelint

@buildinams/lint/stylelint

This is our base config for all SCSS projects with CSS Modules. It extends:

• stylelint-config-recommended-scss
• stylelint-config-css-modules
• stylelint-config-rational-order
• stylelint-declaration-block-no-ignored-properties

For the most part we've tried to simply inherit rules from the above configs, but we've also added a few custom rules:

• scss/selector-no-redundant-nesting-selector
• indentation - Enforced tab spacings.

To use, create a .stylelintrc.json and extend the config:

{
	"extends": "./node_modules/@buildinams/lint/stylelint"
}

Lastly, this config also enforces scss/function-no-unknown to prevent the use of unknown functions. As you define functions in your project, we recommend you add them to the ignoreFunctions array in the config. For example:

{
	"extends": "./node_modules/@buildinams/lint/stylelint",
	"rules": {
		"scss/function-no-unknown": [true, { "ignoreFunctions": ["px-to-rem"] }]
	}
}

This adds a level of type safety to your SCSS, and prevents developers from using functions that don't 'exist'.

Using 'tab' Spacings

Different developers have different preferences when it comes down to spacing sizes. To make sure everyone can have what they want visually, we've decided to enforce tabs over spaces. This means one developer can have tabs render as 4 spaces and another as 2 spaces without it effecting the codebase.

Using With Prettier

As you'll notice, this package doesn't contain any custom .pretterrc.json config to extend. We recommend not including it, and instead just inheriting the default config (by not creating / changing it).

Enabling Prettier on Save in VSCode

To use Prettier on save, you'll need to install the following VSCode extensions:

• dbaeumer.vscode-eslint
• esbenp.prettier-vscode

To then enable format on save in VScode, open your workspace settings (Shift-Command-P and select Open Workspace Settings (JSON)), then paste the following into /.vscode/settings.json:

{
	"editor.formatOnSave": false,
	"editor.defaultFormatter": "esbenp.prettier-vscode",
	"editor.codeActionsOnSave": {
		"source.fixAll.eslint": "explicit"
	}
}

Enabling Stylelint on Save in VSCode

To use Stylelint on save, you'll need to install the stylelint.vscode-stylelint extension.

To then enable format on save in VScode, open your workspace settings (see above for how to open workspace settings), then paste the following into /.vscode/settings.json:

{
	"editor.formatOnSave": false,
	"scss.validate": false,
	"stylelint.validate": ["scss"],
	"editor.codeActionsOnSave": {
		"source.fixAll.stylelint": "explicit"
	}
}

Requirements

This library requires a minimum React version of 17.0.0.

Requests and Contributing

Found an issue? Want a new feature? Get involved! Please contribute using our guideline here.