-
Notifications
You must be signed in to change notification settings - Fork 1
The scriptlint "standard"
We're using the word "standard" in quotes, because it is a rather big word for something so simple: there are two stages of rules: a default, minimum one and a strict one. If you choose to use the scriptlint CLI package, this is reflected in the strict
/--strict
option. The default rules should be relatively easy to fulfil and don't require many changes to get your project up to this standard.
Additionally we have a set of best practices, documented here, but not enforced in the CLI package.
They represent the bare minimum of what we expect from any "scripts"
section:
Every package.json has to have at least these 3 scripts:
{
"scripts": {
"start": "...",
"test": "...",
"dev": "...",
}
}
Note: if you have a project, where having for example a start
script doesn't make sense, feel free to alias it to something else like dev
or you keep it as a stub, for example "start": "echo \"start what?\""
.
This is the default test from npm init
:
{
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
}
}
You should not leave that in your scripts. Usually, any project has at least one method of quick code verification. When in doubt, try to alias it to your build script, that's better than nothing.
- uses-allowed-namespace
- alphabetic-order
- correct-casing
- no-aliases
- prepost-trigger-defined
- no-unix-double-ampersand
- no-unix-single-ampersand
These rules are neither minimum nor strict and therefore must be explicitly enabled in the config. See natural-order for an example.
- Motivation
- The scriptlint "standard" tl;dr
-
The scriptlint "standard"
- Rules enforceable via the scriptlint CLI
- Best practices
- The scriptlint CLI
- Contributing to scriptlint