Awesome
The ESLint custom plugin with rules and parser for .brs
files.
ESLint plugin for BrightScript
We going to skip the part why linting is important so you can read more about it at ESLint site. Primary motivation for this development is absence of reliable tools for Roku development (at least at the time this work started) and performance criteria.
Latest tests gave measurement of about 14 seconds for a 1000 files of BrightScript
This plugin provides parsing and linting tool for your Roku project. While ESLint rules for Javascript are not 1 to 1 replaceable you are able to quickly develop or translate any other rules to work with brightscript. It's written in typescript but could use any JS- technology you like
VSCode Integration
"eslint.validate": [ {
"language": "brightscript",
"autoFix": false
} ],
Linter Warnings
Syntax Errors
Disable rules with comments
? "this is a valid log" ' eslint-disable-line
or
' eslint-disable-next-line [rule]
? "this is a valid log"
note: whole file eslint-disable
does not work as there is no block quote in brightscript
Installation
You'll first need to install ESLint:
With Yarn
yarn add --dev eslint
With npm
$ npm i eslint --save-dev
Next, install eslint-plugin-roku
:
With Yarn
yarn add --dev eslint-plugin-roku
With npm
$ npm install eslint-plugin-roku --save-dev
Note: If you installed ESLint globally (using the -g
flag) then you must also install eslint-plugin-roku
globally.
Configuration
{
"extends": "plugin:roku/recommended",
"rules": {
"roku/no-print": "error",
"roku/no-stop": "warn",
"roku/sub-to-function": "warn",
"roku/function-no-return": "warn",
"roku/no-unused-params": "warn",
"roku/function-no-return-type": "warn",
"roku/function-name-camelcase": "warn",
"roku/no-uninitialized-variables": "error",
"roku/no-uninitialized-functions": "error",
}
}
Plugin-Provided Rules
Just as any other project this one requires more feedback and linting rules ideas
Parsing and AST
This documentation will be available at https://github.com/RokuRoad/bright
Writing rules
https://eslint.org/docs/developer-guide/working-with-rules
Testing rules
Typical test for a rule will look like
Test runner and valid / invalid factories to wrap your test code into testable solution
import { invalidFactory, runTest, validFactory } from '../helpers'
Define name of your rule, it will be used to require it and run tests
const RULE_NAME = 'sub-to-function'
Provide prefix and suffix, so you can test function body or root element like library import of the function itself
const valid = validFactory(RULE_NAME, '', '')
const invalid = invalidFactory(RULE_NAME, '', '')
Define cases to match against. Invalid cases will provide error messages
runTest(RULE_NAME, {
invalid: [
[
`sub a() as Dynamic
end sub`,
[ { message: 'Sub a should not have a return type (dynamic). Consider replacing it with Function' } ]
]
].map(invalid),
valid: [
`sub a()
print a
end sub
`
].map(valid)
})
SceneGraph
Currently in development, check back soon. Rule will be aware of components tree structure so for instance if function is going to be overwritten or just mistakenly left empty.