eslint-plugin-canonical
ESLint rules for Canonical ruleset.
Installation
npm install eslint --save-dev
npm install @typescript-eslint/parser --save-dev
npm install eslint-plugin-canonical --save-dev
Configuration
- Set
parser
property to @typescript-eslint/parser
. - Add
plugins
section and specify eslint-plugin-canonical
as a plugin. - Enable rules.
{
"parser": "@typescript-eslint/parser",
"plugins": [
"canonical"
],
"rules": {
"canonical/filename-match-exported": 0,
"canonical/filename-match-regex": 0,
"canonical/filename-no-index": 0,
"canonical/id-match": [
2,
"(^[A-Za-z]+(?:[A-Z][a-z]*)*\\d*$)|(^[A-Z]+(_[A-Z]+)*(_\\d$)*$)|(^(_|\\$)$)",
{
"ignoreDestructuring": true,
"ignoreNamedImports": true,
"onlyDeclarations": true,
"properties": true
}
],
"canonical/no-restricted-strings": 0,
"canonical/no-use-extend-native": 2,
"canonical/prefer-inline-type-import": 2
}
}
Shareable configurations
Recommended
This plugin exports a recommended configuration that enforces Canonical type good practices.
To enable this configuration use the extends property in your .eslintrc
config file:
{
"extends": [
"plugin:canonical/recommended"
],
"plugins": [
"canonical"
]
}
See ESLint documentation for more information about extending configuration files.
Rules
destructuring-property-newline
Like object-property-newline
, but for destructuring.
📖 Examples
The following patterns are considered problems:
const {a,b} = obj;
const [a,b] = obj;
const {a,b,c} = obj;
const {
a,b} = obj;
({a,b}) => {};
The following patterns are not considered problems:
const {a,
b} = obj;
const {a,b} = obj;
const [a,b] = obj;
const {a} = obj;
const {
a
} = obj;
({a,
b}) => {};
const [a,,b] = obj;
export-specifier-newline
Forces every export specifier to be on a new line.
Tip: Combine this rule with object-curly-newline
to have every specifier on its own line.
"object-curly-newline": [
2,
{
"ExportDeclaration": "always"
}
],
Working together, both rules will produces exports such as:
export {
a,
b,
c
};
📖 Examples
The following patterns are considered problems:
const a = 1; const b = 2; const c = 3; export { a, b, c };
const a = 1; const b = 2; const c = 3; export { a, b, c, };
const a = 1; const b = 2; export { a as default, b }
The following patterns are not considered problems:
export {
a,
b,
c
} from 'foo'
const a = 1; const b = 2; const c = 3; export {
a,
b,
c
};
export * from 'foo'
filename-match-exported
Match the file name against the default exported value in the module. Files that don't have a default export will be ignored. The exports of index.js
are matched against their parent directory.
export default function foo() {}
module.exports = class Foo() {}
module.exports = someVariable;
export default { foo: "bar" };
If your filename policy doesn't quite match with your variable naming policy, you can add one or multiple transforms:
"canonical/filename-match-exported": [ 2, { "transforms": "kebab" } ]
Now, in your code:
export default function variableName;
Available transforms:
For multiple transforms simply specify an array like this (null in this case stands for no transform):
"canonical/filename-match-exported": [2, { "transforms": [ null, "kebab", "snake" ] } ]
If you prefer to use suffixes for your files (e.g. Foo.react.js
for a React component file), you can use a second configuration parameter. It allows you to remove parts of a filename matching a regex pattern before transforming and matching against the export.
"canonical/filename-match-exported": [ 2, { "suffix": "\\.react$" } ]
Now, in your code:
export default function variableName;
If you also want to match exported function calls you can use the third option (a boolean flag).
"canonical/filename-match-exported": [ 2, { "matchCallExpression": true } ]
Now, in your code:
export default functionName();
📖 Examples
The following patterns are considered problems:
module.exports = exported;
module.exports = class Foo {};
module.exports = class Foo { render() { return <span>Test Class</span>; } };
module.exports = function foo() {};
module.exports = function foo() { return <span>Test Fn</span> };
export default exported;
export default class Foo {};
export default class Foo { render() { return <span>Test Class</span>; } };
export default function foo() {};
export default function foo() { return <span>Test Fn</span> };
module.exports = exported;
module.exports = class Foo { render() { return <span>Test Class</span>; } };
module.exports = variableName;
export default variableName;
export default variableName;
export default variableName;
export default class Foo { render() { return <span>Test Class</span>; } };
export default class Foo { render() { return <span>Test Class</span>; } };
module.exports = foo();
The following patterns are not considered problems:
module.exports = function() {};
var foo = 'bar';
export default foo();
module.exports = exported;
module.exports = class Foo {};
module.exports = class Foo { render() { return <span>Test Class</span>; } };
module.exports = function foo() {};
module.exports = foo();
module.exports = function foo() { return <span>Test Fn</span> };
export default exported;
export default class Foo {};
export default class Foo { render() { return <span>Test Class</span>; } };
export default function foo() {};
export default function foo() { return <span>Test Fn</span> };
export default function foo() {};
export default function foo() { return <span>Test Fn</span> };
export default function index() {};
module.exports = variableName;
module.exports = variableName;
module.exports = variableName;
module.exports = variable_name;
export default variableName;
export default variableName;
export default variable_name;
export default variable_name;
export default variable_name;
export default variable_name;
module.exports = class Foo { render() { return <span>Test Class</span>; } };
export default class Foo { render() { return <span>Test Class</span>; } };
module.exports = foo();
filename-match-regex
Enforce a certain file naming convention using a regular expression.
The convention can be configured using a regular expression (the default is camelCase.js
). Additionally
exporting files can be ignored with a second configuration parameter.
"canonical/filename-match-regex": [2, { "regex": "^[a-z_]+$", "ignoreExporting": true }]
With these configuration options, camelCase.js
will be reported as an error while snake_case.js
will pass.
Additionally the files that have a named default export (according to the logic in the match-exported
rule) will be
ignored. They could be linted with the match-exported
rule. Please note that exported function calls are not
respected in this case.
📖 Examples
The following patterns are considered problems:
var foo = 'bar';
var foo = 'bar';
var foo = 'bar';
var foo = 'bar';
The following patterns are not considered problems:
var foo = 'bar';
var foo = 'bar';
var foo = 'bar';
var foo = 'bar';
var foo = 'bar';
var foo = 'bar';
module.exports = foo
module.exports = foo
module.exports = foo()
filename-no-index
Having a bunch of index.js
files can have negative influence on developer experience, e.g. when
opening files by name. When enabling this rule. index.js
files will always be considered a problem.
📖 Examples
The following patterns are considered problems:
var foo = 'bar';
var foo = 'bar';
The following patterns are not considered problems:
var foo = 'bar';
var foo = 'bar';
var foo = 'bar';
var foo = 'bar';
id-match
The --fix
option on the command line automatically fixes problems reported by this rule.
Note: This rule is equivalent to id-match
, except for addition of ignoreNamedImports
.
This rule requires identifiers in assignments and function
definitions to match a specified regular expression.
Options
"properties": false
(default) does not check object properties"properties": true
requires object literal properties and member expression assignment properties to match the specified regular expression"classFields": false
(default) does not class field names"classFields": true
requires class field names to match the specified regular expression"onlyDeclarations": false
(default) requires all variable names to match the specified regular expression"onlyDeclarations": true
requires only var
, function
, and class
declarations to match the specified regular expression"ignoreDestructuring": false
(default) enforces id-match
for destructured identifiers"ignoreDestructuring": true
does not check destructured identifiers"ignoreNamedImports": false
(default) enforces id-match
for named imports"ignoreNamedImports": true
does not check named imports
📖 Examples
The following patterns are considered problems:
var __foo = "Matthieu"
first_name = "Matthieu"
first_name = "Matthieu"
Last_Name = "Larcher"
var obj = {key: no_under}
function no_under21(){}
obj.no_under22 = function(){};
no_under23.foo = function(){};
[no_under24.baz]
if (foo.bar_baz === boom.bam_pow) { [no_under25.baz] }
foo.no_under26 = boom.bam_pow
var foo = { no_under27: boom.bam_pow }
foo.qux.no_under28 = { bar: boom.bam_pow }
var o = {no_under29: 1}
obj.no_under30 = 2;
var { category_id: category_alias } = query;
var { category_id: category_alias } = query;
var { category_id: categoryId, ...other_props } = query;
var { category_id } = query;
var { category_id = 1 } = query;
import no_camelcased from "external-module";
import * as no_camelcased from "external-module";
export * as no_camelcased from "external-module";
import { no_camelcased as no_camel_cased } from "external module";
import { camelCased as no_camel_cased } from "external module";
import { camelCased, no_camelcased } from "external-module";
import { no_camelcased as camelCased, another_no_camelcased } from "external-module";
import camelCased, { no_camelcased } from "external-module";
import no_camelcased, { another_no_camelcased as camelCased } from "external-module";
function foo({ no_camelcased }) {};
function foo({ no_camelcased = 'default value' }) {};
const no_camelcased = 0; function foo({ camelcased_value = no_camelcased }) {}
const { bar: no_camelcased } = foo;
function foo({ value_1: my_default }) {}
function foo({ isCamelcased: no_camelcased }) {};
var { foo: bar_baz = 1 } = quz;
const { no_camelcased = false } = bar;
class x { _foo() {} }
class x { _foo = 1; }
import { no_camelcased } from "external-module";
The following patterns are not considered problems:
__foo = "Matthieu"
firstname = "Matthieu"
first_name = "Matthieu"
firstname = "Matthieu"
last_Name = "Larcher"
param = "none"
function noUnder(){}
no_under()
foo.no_under2()
var foo = bar.no_under3;
var foo = bar.no_under4.something;
foo.no_under5.qux = bar.no_under6.something;
if (bar.no_under7) {}
var obj = { key: foo.no_under8 };
var arr = [foo.no_under9];
[foo.no_under10]
var arr = [foo.no_under11.qux];
[foo.no_under12.nesting]
if (foo.no_under13 === boom.no_under14) { [foo.no_under15] }
var myArray = new Array(); var myDate = new Date();
var x = obj._foo;
var obj = {key: no_under}
var {key_no_under: key} = {}
var { category_id } = query;
var { category_id: category_id } = query;
var { category_id = 1 } = query;
var o = {key: 1}
var o = {no_under16: 1}
obj.no_under17 = 2;
var obj = {
no_under18: 1
};
obj.no_under19 = 2;
obj.no_under20 = function(){};
var x = obj._foo2;
class x { foo() {} }
class x { #foo() {} }
import { no_camelcased } from "external-module";
const {
index,
'0': n0,
'1': n1,
} = exampleCode;
import-specifier-newline
Forces every import specifier to be on a new line.
Tip: Combine this rule with object-curly-newline
to have every specifier on its own line.
"object-curly-newline": [
2,
{
"ImportDeclaration": "always"
}
],
Working together, both rules will produces imports such as:
import {
a,
b,
c
} from 'foo';
📖 Examples
The following patterns are considered problems:
import {a, b} from 'foo';
import a, {b, c} from 'foo';
The following patterns are not considered problems:
import {a,
b} from 'foo'
import a, {b,
c} from 'foo'
no-barrel-import
The --fix
option on the command line automatically fixes problems reported by this rule.
Requires that resources are imported from the same files in which they are defined.
This rule converts the following:
import { bar } from './bar';
export { baz as bar } from './baz';
export const baz = 'BAZ';
to:
import { baz as bar } from './baz';
export const baz = 'BAZ';
This rule handles
- named imports
- default imports
- aliased imports
You must configure import/parsers
and import/resolver
for this rule to work, e.g.
settings: {
'import/parsers': {
'@typescript-eslint/parser': ['.ts', '.tsx'],
},
'import/resolver': {
typescript: {
project: path.resolve(
__dirname,
'tsconfig.json',
),
},
},
},
📖 Examples
The following patterns are considered problems:
import { foo } from './bar';
import { foo as FOO } from './bar';
import { bar } from './bar';
import { foo } from './baz';
import foo from './bar';
import { type Foo } from './bar';
import { foo, bar } from './bar';
The following patterns are not considered problems:
import { foo } from './foo';
import foo from './foo';
import { logLevels } from 'roarr';
no-export-all
The --fix
option on the command line automatically fixes problems reported by this rule.
Requite that re-exports are named.
📖 Examples
The following patterns are considered problems:
export * from './foo';
export * from './foo';
The following patterns are not considered problems:
export { FOO } from './foo';
export * as foo from './foo';
no-import-namespace-destructure
Disallows the practice of importing an entire module's namespace using import * as Namespace and then destructuring specific exports from it. Instead, it encourages direct importing of only the necessary named exports from a module.
📖 Examples
The following patterns are considered problems:
import * as bar from 'bar'; const { foo } = bar;
The following patterns are not considered problems:
import * as bar from 'bar'
no-re-export
Disallows re-exports of imports.
📖 Examples
The following patterns are considered problems:
import Button1 from 'app/CustomButton';
export const CustomButton = Button1;
import { Button as CustomButton2 } from 'app/CustomButton';
export const CustomButton = CustomButton2;
import * as Button3 from "app/Button";
export const CustomButton = Button3;
import Button4 from 'app/CustomButton';
export default Button4;
export { default as Button5 } from 'app/CustomButton';
import Button6 from 'app/CustomButton';
export {
Button6
};
import Button7 from 'app/CustomButton';
export const Buttons = {
Button: Button7
};
import Button8 from 'app/CustomButton';
export default Button8;
export { Button8 }
export * from 'app/CustomButton';
[!NOTE]
This rule was originally developed by @christianvuerings as part of https://github.com/christianvuerings/eslint-plugin-no-re-export
no-reassign-imports
Restricts re-assigning imports to variables that are exported.
📖 Examples
The following patterns are considered problems:
import { Foo } from './Foo';
export const Bar = {
Foo,
};
import { Foo } from './Foo';
export default {
Foo,
};
no-restricted-imports
Disallow specified modules when loaded by import
This rule is similar to no-restricted-imports
except that it allows you to specify unique messages for each restricted import (a workaround for issue issues#15261).
Note: Unlike the ESLint rule, this rule does not support the patterns
option and it does not handle exports.
📖 Examples
The following patterns are considered problems:
import * as bar from 'bar'
import { foo } from 'bar'
import { default as bar } from 'bar'
import bar from 'bar'
The following patterns are not considered problems:
import { bar } from 'bar'
no-restricted-strings
Disallow specified strings.
📖 Examples
The following patterns are considered problems:
var foo = "bar"
const foo = `bar ${baz}`;
The following patterns are not considered problems:
const foo = "bar";
Options
The 1st option is an array of strings that cannot be contained in the codebase.
no-unused-exports
Identifies unused TypeScript exports.
Note This rule is implemented using ts-unused-exports
.
Options
Config | Type | Required | Default | Description |
---|
tsConfigPath | string | Required | | Path to tsconfig.json |
allowUnusedEnums | boolean | | false | Allow unused enum s. |
allowUnusedTypes | boolean | | false | Allow unused type and interface . |
📖 Examples
The following patterns are considered problems:
export const FOO = '';
The following patterns are not considered problems:
export const BAR = '';
no-use-extend-native
📖 Examples
The following patterns are considered problems:
Array.prototype.custom
Array.to
Array.to()
[].length()
'unicorn'.green
[].custom()
({}).custom()
/match_this/.custom()
'string'.custom()
console.log('foo'.custom)
console.log('foo'.custom())
('str' + 'ing').custom()
('str' + 'i' + 'ng').custom()
(1 + 'ing').custom()
(/regex/ + 'ing').custom()
(1 + 1).toLowerCase()
(1 + 1 + 1).toLowerCase()
(function testFunction() {}).custom()
new Array().custom()
new ArrayBuffer().custom()
new Boolean().custom()
new DataView().custom()
new Date().custom()
new Error().custom()
new Float32Array().custom()
new Float64Array().custom()
new Function().custom()
new Int16Array().custom()
new Int32Array().custom()
new Int8Array().custom()
new Map().custom()
new Number().custom()
new Object().custom()
new Promise().custom()
new RegExp().custom()
new Set().custom()
new String().custom()
new Symbol().custom()
new Uint16Array().custom()
new Uint32Array().custom()
new Uint8Array().custom()
new Uint8ClampedArray().custom()
new WeakMap().custom()
new WeakSet().custom()
new Array()['custom']
new Array()['custom']()
The following patterns are not considered problems:
error.plugin
error.plugn()
array.custom
Object.assign()
Object.keys
Object.keys()
gulp.task()
Custom.prototype.custom
Array.prototype.map
Array.prototype.map.call([1,2,3], function (x) { console.log(x) })
Array.apply
Array.call(null, 1, 2, 3)
[].push(1)
[][0]
{}[i]
{}[3]
{}[j][k]
({foo: {bar: 1, baz: 2}}[i][j])
({}).toString()
/match_this/.test()
'foo'.length
'hi'.padEnd
'hi'.padEnd()
console.log('foo'.length)
console.log('foo'.toString)
console.log('foo'.toString())
console.log(gulp.task)
console.log(gulp.task())
'string'.toString()
(1).toFixed()
1..toFixed()
1.0.toFixed()
('str' + 'ing').toString()
('str' + 'i' + 'ng').toString()
(1 + 1).valueOf()
(1 + 1 + (1 + 1)).valueOf()
(1 + 1 + 1).valueOf()
(1 + 'string').toString()
(/regex/ + /regex/).toString()
(/regex/ + 1).toString()
([1] + [2]).toString()
(function testFunction() {}).toString()
Test.prototype
new Array().toString()
new ArrayBuffer().constructor()
new Boolean().toString()
new DataView().buffer()
new Date().getDate()
new Error().message()
new Error().stack
new Error().stack.slice(1)
new Float32Array().values()
new Float64Array().values()
new Function().toString()
new Int16Array().values()
new Int32Array().values()
new Int8Array().values()
new Map().clear()
new Number().toString()
new Object().toString()
new Object().toString
new Promise().then()
new RegExp().test()
new Set().values()
new String().toString()
new Symbol().toString()
new Uint16Array().values()
new Uint32Array().values()
new Uint8ClampedArray().values()
new WeakMap().get()
new WeakSet().has()
new Array()['length']
new Array()['toString']()
prefer-import-alias
The --fix
option on the command line automatically fixes problems reported by this rule.
Restrict imports to path aliases or relative imports limited by depth.
The same alias can be applied using multiple rules, e.g.
'canonical/prefer-import-alias': [
2,
{
aliases: [
{
alias: '@/',
matchParent: path.resolve(__dirname, 'src'),
matchPath: '^src\\/',
},
{
alias: '@/',
matchPath: '^src\\/',
maxRelativeDepth: 2,
},
],
},
],
In this example, we are saying:
- rewrite import path to use alias when
- import path matches
^src\/
- the grandfather directory is
path.resolve(__dirname, 'src')
- rewrite import path to use alias when
- import path matches
^src\/
- relative import is greater than 2
The grandfather directory is essentially whichever directory that is accessed by the doubledot (../
) by the import path.
📖 Examples
The following patterns are considered problems:
import { bar } from './bar';
import { baz } from '../baz';
import { bar } from '../bar';
The following patterns are not considered problems:
import { bar } from '../bar';
import { foo } from '@bar/baz';
import Foo from '@bar/baz';
import Foo, { Foo } from 'bar';
import { foo } from './foo';
import { foo } from '../foo';
import { foo } from '.././foo';
import { foo } from '././../foo';
import { foo } from '@bar/baz';
import { foo } from '../../foo';
prefer-inline-type-import
The --fix
option on the command line automatically fixes problems reported by this rule.
TypeScript 4.5 introduced type modifiers that allow to inline type imports as opposed to having dedicated import type
. This allows to remove duplicate type imports. This rule enforces use of import type modifiers.
📖 Examples
The following patterns are considered problems:
import type {foo} from 'bar'
import type {foo, baz} from 'bar'
The following patterns are not considered problems:
import {type foo} from 'bar'
import type Foo from 'bar'
import type * as Foo from 'bar'
prefer-react-lazy
Requires that components that can be loaded lazily be imported using the React.lazy()
function.
import { lazy } from 'react';
import { Foo } from './Foo';
export default () => {
return Math.random() > 0.5 ? <Foo /> : null;
};
This rule converts the above code to:
import { lazy } from 'react';
const Foo = lazy(() => import('./Foo.js').then(({ Foo }) => ({ default: Foo })));
export default () => {
return Math.random() > 0.5 ? <Foo /> : null;
};
📖 Examples
The following patterns are considered problems:
import React from 'react';
import { Foo } from './Foo';
export default () => {
return <>
{Math.random() > 0.5 ? <Foo /> : null}
</>;
};
import React from 'react';
import { Foo } from './Foo';
export default () => {
return <>
{Math.random() > 0.5 ? <div>
<Foo />
</div> : null}
</>;
};
import React from 'react';
import { Foo } from './Foo';
export default () => {
return Math.random() > 0.5 ? <Foo /> : null;
};
The following patterns are not considered problems:
import React, { lazy } from 'react';
const Foo = lazy(() => import('./Foo').then(({ Foo }) => ({ default: Foo })));
export default () => {
return Math.random() > 0.5 ? <Foo /> : null;
};
prefer-use-mount
In React, it is common to use useEffect
without dependencies when the intent is to run the effect only once (on mount and unmount). However, just doing that may lead to undesired side-effects, such as the effect being called twice in Strict Mode. For this reason, it is better to use an abstraction such as useMount
that handles this use case.
📖 Examples
The following patterns are considered problems:
useEffect(() => {}, [])
The following patterns are not considered problems:
useEffect(() => {}, [foo])
useMount(() => {}, [])
require-extension
The --fix
option on the command line automatically fixes problems reported by this rule.
Adds .js
extension to all imports and exports.
It resolves the following cases:
Relative imports
Relative imports that resolve to a file of the same name:
import './foo';
Relative imports that resolve to an index file:
import './foo';
The above examples would also work if the file extension was .ts
or .tsx
, i.e.
import './foo';
import './foo';
TypeScript paths
For this to work, you have to configure import/resolver
:
settings: {
'import/resolver': {
typescript: {
project: path.resolve(__dirname, 'tsconfig.json'),
},
},
},
Imports that resolve to a file of the same name:
import { foo } from '@/foo';
Imports that resolve to an index file:
import { foo } from '@/foo';
📖 Examples
The following patterns are considered problems:
import { foo } from '@/foo';
import { foo } from '@/foo';
import { foo } from '@/foo';
import { foo } from './foo';
import { foo } from './foo';
export { foo } from './foo';
export * from './foo';
The following patterns are not considered problems:
import { foo } from './foo.svg?url';
import { foo } from '@/foo.css';
import { foo } from '@/foo.js';
import { foo } from './foo.css';
import { foo } from './foo.js';
import { Roarr } from 'roarr';
import { Chance } from 'chance';
sort-react-dependencies
The --fix
option on the command line automatically fixes problems reported by this rule.
Requires that dependencies of React methods (useEffect
, useCallback
and useMemo
) are sorted alphabetically.
📖 Examples
The following patterns are considered problems:
useEffect(() => {}, [b, a])
useEffect(() => {}, [a, B])
The following patterns are not considered problems:
useEffect(() => {}, [a, b])
FAQ
Why is the @typescript-eslint/parser
?
This ESLint plugin is written using @typescript-eslint/utils
, which assume that @typescript-eslint/parser
is used.
Some rules may work without @typescript-eslint/parser
. However, rules are implemented and tested assuming that @typescript-eslint/parser
is used.