Shareable configs are configurations that you can use and extend from. They can be useful for using the same base configuration in all your projects or for basing your configuration from a well-known one.
To use a shareable config, you have to add it to your Solhint configuration:
{
"extends": ["solhint:recommended", "protofire"]
}
This example shows the two types of shareable configs that you can use:
solhint: (e.g. solhint:recommended, solhint:all)Unscoped shareable configs are npm packages prefixed with solhint-config-.
For example, this configuration:
{
"extends": ["protofire"]
}
Will load the package:
solhint-config-protofire
which must be installed beforehand:
npm install solhint-config-protofire
You can also reference the full package name explicitly:
{
"extends": ["solhint-config-protofire"]
}
Shareable configs are resolved from the project’s node_modules directory (the current working directory), even when Solhint is installed globally.
Solhint also supports scoped shareable configs.
Given the npm package:
@scope/solhint-config-myconfig
You can use it in your configuration as:
{
"extends": ["@scope/solhint-config-myconfig"]
}
For convenience, Solhint also supports the ESLint-style shorthand:
{
"extends": ["@scope/myconfig"]
}
Which resolves to:
@scope/solhint-config-myconfig
Note: Only package-level scoped configs are supported (@scope/name). Deep paths such as @scope/name/extra are not supported.
Shareable configs are regular npm packages. There are only two conditions:
solhint-config-@scope/solhint-config-*).solhint.json)For example, a very minimal index.js in this package could be:
module.exports = {
rules: {
'max-line-length': 80
}
}
After creating this package, you can publish it to npm to make it available for everyone.
Solhint supports hierarchical configuration.
When linting a file, configurations are merged in the following order:
For each configuration file, any extends entries are resolved first, and then all configurations are merged according to directory hierarchy.
Rules and settings defined in deeper directories override those from higher-level directories and from extended configs.
In short:
extends are resolved first, directory hierarchy is applied after, and the closest config always wins.