feat: show eslint warnings

This removes the `--quiet` flag from the ESLint invocation, and fixes
the broken output where ESLint complains about us trying to lint
dot-files and folders by un-ignoring their built-in ignore filters.

We agree with ignoring node_modules in terms of linting however, so that
is left in place.

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
 
@@ -14,3 +14,31 @@ You can reinstall it using 'npm install husky --save-dev' or delete this hook
 ```
 
 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 to `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 not fun to add `d2-style` when the codebase has grown and
+accumulated what is considered lint. Everything as errors means that it
+will take real effort to de-lint the codebase.
+
+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.
+
+So `d2-style` operates with two levels: `--strict` and `--no-strict`.
+
+In both modes, errors are considered problems significant enough that
+they cannot be allowed into the code base.
+
+In strict mode, warnings are NOT allowed into the code base.
+
+In the non-strict mode, warnings are allowed into the code base and can
+be used as an interim solution to allow for planned de-linting.

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] : []),