@lightscript/eslint-plugin
v4.0.0-alpha.38
Published
LightScript plugin for the ESLint linter.
Downloads
5
Maintainers
Readme
@lightscript/eslint-plugin
A first-class linter for LightScript built on ESLint 5.
Issues: https://github.com/wcjohnson/lightscript/issues
TLDR
Install stuff:
$ npm install --save-dev eslint $ npm install --save-dev @lightscript/eslint-plugin $ npm install --save-dev @lightscript/babel-preset
Create or update
.eslintrc
at your package root:{ "parser": "@lightscript/eslint-plugin", "plugins": ["@lightscript/eslint-plugin"], "extends": [ "plugin:@lightscript/recommended" ] }
Lint your source code:
$ (npm bin)/eslint --ext .js,.lsc src/
@lightscript/eslint-plugin
is compatible with most other ESLint plugins and can lint JavaScript as well as LightScript code.
The Details
@lightscript/eslint-plugin
is an extension for ESLint (>= 5.0.0)
that parses and statically analyzes LightScript code.
It is based on the babel-eslint
plugin and has been modified to support LightScript AST.
Any file that includes .lsc
or .lsx
in the filename (including, eg, .lsc.js
)
will be processed as LightScript; all others will be processed exactly as in babel-eslint
.
@lightscript/babel-preset
is a peerDependency and must be installed alongside the linter plugin. If you have a working LightScript build chain, this should already be the case.
Usage
@lightscript/eslint-plugin
is both a parser and plugin for ESLint 5 (>= 5.0.0)
. In order to use it, it must be added
to your ESLint configuration as both a parser and a plugin:
{
"parser": "@lightscript/eslint-plugin",
"plugins": ["@lightscript/eslint-plugin"]
}
No further configuration is specifically required in order to use the plugin, but to get the most out of it, we recommend enabling
our recommended
ruleset. Our recommended
ruleset includes the basic ESLint recommended ruleset, along with disabling some broken rules and adding LightScript-specific rules. Enable it by adding the following to your config:
{
"extends": [
"plugin:@lightscript/recommended"
]
}
When running eslint
from the CLI, you must tell it to process LightScript file extensions:
$ eslint --ext .js,.lsc src/
Live Linting
Visual Studio Code
- Set up eslint for your project as above. Verify that eslint lints correctly from the CLI.
- Install the
LightScript
extension for VSCode: https://marketplace.visualstudio.com/items?itemName=lightscript.lsc - Install the
ESLint
extension for VSCode: https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint - Tell VSCode to live-lint LightScript files by adding the following entry to your VSCode options (workspace or global):
"eslint.validate": [ "javascript", "javascriptreact", "lightscript" ]
Rules
@lightscript/eslint-plugin
provides a number of linting rules designed specifically for LightScript code. Rules are configured using the standard ESLint mechanisms, e.g. by adding the rule to your .eslintrc
:
{
"rules": {
"@lightscript/unnecessary-const": 1
}
}
Some rules contain automated fixes. You can apply these autofixes to a file using the ESLint CLI:
$ eslint --fix src/fileToFix.lsc
@lightscript/variables
Warns about erroneous use of variables and assignment in LightScript, including missing now
keywords and illegal variable shadowing. As these errors will prevent your code from compiling, this rule should always be enabled when linting LightScript code.
- Included in
recommended
preset. - Contains automatic fixes for missing
now
.
@lightscript/no-illegal-in-iife
Warns about the use of language constructs that are illegal because the compiler will generate an IIFE around them. These notices should be treated as fatal, as the compiler will throw an error in such cases. This rule should always be enabled when linting LightScript code.
- Included in
recommended
preset.
@lightscript/no-implicit-imports
Warn whenever the use of an identifier would trigger an implicit import by the compiler. Such instances are not necessarily errors, but can be handy so that you don't accidentally implicitly import something.
@lightscript/match-requires-else
Warn when a match
is missing an else
case. Can be used to ensure all pattern matches are exhaustive.
@lightscript/no-unnecessary-const
Warn when a const
keyword is unnecessary because of LightScript implicit const
.
- Included in
recommended
preset.
@lightscript/no-unnecessary-semi
Warn when a ;
is unnecessary according to LightScript ASI rules.
- Included in
recommended
preset.
@lightscript/no-unnecessary-comma
Warn when a ,
is unnecessary according to LightScript list separator rules.
- Included in
recommended
preset.
Known Issues
Issues with hoisting ESLint outside of package root (e.g. Lerna, Yarn workspaces) If ESLint is hoisted outside of the root
node_modules
folder of your package, it will not be able to find the plugin and you will encounter "can't find plugin" errors. To fix this, use thenohoist
option of your monorepo tool to ensure ESLint is not hoisted out of your package.no-extra-semi
rule: When linting LightScript files, this rule is automatically disabled. We recommend the@lightscript/unnecessary-semi
rule instead.array-callback-return
rule: When linting LightScript files, this rule is automatically disabled. This rule is broken pending changes to ESLint's code path analysis; see this issuereact/require-render-return
rule: When linting LightScript files, this rule is automatically disabled. Because of LightScript's implicit returns, this rule is almost always superfluous.
Flow:
Check out eslint-plugin-flowtype: An
eslint
plugin that makes flow type annotations global variables and marks declarations as used. Solves the problem of false positives withno-undef
andno-unused-vars
.
no-undef
for global flow types:ReactElement
,ReactClass
#130- Workaround: define types as globals in
.eslintrc
or define types and import themimport type ReactElement from './types'
- Workaround: define types as globals in
no-unused-vars/no-undef
with Flow declarations (declare module A {}
) #132
Modules/strict mode
no-unused-vars: [2, {vars: local}]
#136
Please check out eslint-plugin-react for React/JSX issues
no-unused-vars
with jsx
Please check out eslint-plugin-babel for other issues
Contributing
Issues: https://github.com/wcjohnson/lightscript/issues
Deep Dives
parserOptions
sourceType
can be set to'module'
(default) or'script'
if your code isn't using ECMAScript modules.allowImportExportEverywhere
(defaultfalse
) can be set totrue
to allow import and export declarations to appear anywhere a statement is allowed if your build environment supports that. Otherwise import and export declarations can only appear at a program's top level.codeFrame
(defaulttrue
) can be set tofalse
to disable the code frame in the reporter. This is useful since some eslint formatters don't play well with it.
{
"parser": "@lightscript/eslint-plugin",
"parserOptions": {
"sourceType": "module",
"allowImportExportEverywhere": false,
"codeFrame": true
}
}