feat: show eslint warnings

config/js/eslint.config.js

@@ -1,5 +1,3 @@
-const SEVERITY = 2
-
 module.exports = {
  extends: [
  'eslint:recommended',
@@ -8,6 +6,9 @@ module.exports = {
  'plugin:import/warnings',
  ],
 
+ // unignore implicit rules about what types of files can be linted
+ ignorePatterns: ['!.*'],
+
  plugins: ['prettier'],
 
  env: {
@@ -28,22 +29,22 @@ module.exports = {
 
  rules: {
  'max-params': [
- SEVERITY,
+ 'error',
  {
  max: 3,
  },
  ],
  'prefer-const': [
- SEVERITY,
+ 'error',
  {
  destructuring: 'any',
  ignoreReadBeforeAssign: false,
  },
  ],
- 'no-mixed-spaces-and-tabs': [SEVERITY],
- 'prettier/prettier': [SEVERITY],
+ 'no-mixed-spaces-and-tabs': ['error'],
+ 'prettier/prettier': ['error'],
  'import/order': [
- SEVERITY,
+ 'error',
  {
  'newlines-between': 'never',
  alphabetize: {

docs/faq.md

@@ -2,7 +2,7 @@
 
 Some wisdom from Go:
 
-> Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.
+> `gofmt`'s style is no one's favorite, yet `gofmt` is everyone's favorite.
 
 # I'm getting husky errors
 
@@ -16,3 +16,26 @@ You can reinstall it using 'npm install husky --save-dev' or delete this hook
 
 You can remove the husky hooks from `.git/hooks` and opt in to use the
 hooks provided here with e.g. `d2-style install git-hooks/all`.
+
+Ensure that your node and git versions satisfy the above requirements.
+You can check this by running `git --version` and `node --version` from
+your terminal.
+
+# What does an Error and Warnings mean?
+
+`d2-style` is strict by default, as it tries to guard against known lint
+from entering the codebase. If the lint is denied early, it is easier,
+and faster, to fix it.
+
+We set most our style rules as error to serve this purpose. This works
+best when `d2-style` is added to a project that doesn't have a lot of
+code yet.
+
+It is also not fun when `d2-style` decides to adopt new rules as errors.
+That means by simply updating `d2-style` the codebase can be in need of
+significant clean-ups. This is problematic because it can slow adoption
+of new versions of the code style, and it can hold back adoption of new
+and better code style rules.
+
+To allow for gradual adoption of rules, warnings can be used before
+upgrading them to errors.

src/tools/commitlint.js

@@ -1,7 +1,7 @@
 const { COMMITLINT_CONFIG } = require('../utils/paths.js')
 const { bin } = require('../utils/run.js')
 
-exports.commitlint = ({ config = COMMITLINT_CONFIG, file, argv }) => {
+exports.commitlint = ({ config = COMMITLINT_CONFIG, file }) => {
  const cmd = 'commitlint'
  const args = [
  'commitlint',

src/tools/eslint.js

@@ -9,7 +9,6 @@ exports.eslint = ({ files = [], apply = false, config }) => {
  '--no-color',
  '--report-unused-disable-directives',
  '--ignore',
- '--quiet',
  '--format=unix',
  `--resolve-plugins-relative-to=${PACKAGE_ROOT}`,
  ...(ignoreFile ? ['--ignore-path', ignoreFile] : []),