fix: remark-lint, caches and preset-lint-node (nodejs#6006)

* fix: remark-lint, caches and preset-lint-node

* chore: non persistent

.github/workflows/lint-and-tests.yml

@@ -82,6 +82,7 @@ jobs:
             node_modules/.cache
             .eslintmdcache
             .eslintjscache
+            .stylelintcache
             .prettiercache
           # We want to restore Turborepo Cache and ESlint and Prettier Cache
           # The ESLint and Prettier cache's are useful to reduce the overall runtime of ESLint and Prettier
@@ -146,6 +147,7 @@ jobs:
             node_modules/.cache
             .eslintmdcache
             .eslintjscache
+            .stylelintcache
             .prettiercache
           key: cache-lint-${{ hashFiles('package-lock.json') }}-${{ hashFiles('.turbo/cache/**') }}
 

.gitignore

@@ -3,11 +3,6 @@ node_modules
 npm-debug.log
 .npm
 
-# OSX system files, the bane of our existence
-.DS_Store
-.AppleDouble
-.LSOverride
-
 # Next.js Build Output
 .next
 build
@@ -23,19 +18,18 @@ junit.xml
 
 # Storybook
 storybook-static
-.nyc_output
 build-storybook.log
+.nyc_output
 
 # Vercel Files
 .vercel
 .turbo
 cache
 
-# ESlint Cache Files
-.eslintmdcache
+# Cache Files
 .eslintjscache
-
-# Prettier Cache Files
+.eslintmdcache
+.stylelintcache
 .prettiercache
 
 # TypeScript

.prettierignore

@@ -1,26 +1,44 @@
+# Commonly ignored Node.js files
 node_modules
+npm-debug.log
+.npm
 
-# Next.js & Vercel Directories
+# Next.js Build Output
 .next
-.turbo
-.swc
 build
 
-# Files that should not be parsed
-CODEOWNERS
-
-# Public Files
+# Next.js Generated Files
 public/static/documents
-public/node-releases-data.json
-public/blog-posts-data.json
+public/sitemap.xml
+public/en/feed/*.xml
 
-# We don't want to lint/prettify the Coverage Results
+# Jest
 coverage
+.swc
 junit.xml
 
+# Storybook
+storybook-static
+build-storybook.log
+.nyc_output
+
+# Vercel Files
+.vercel
+.turbo
+cache
+
+# Cache Files
+.eslintjscache
+.eslintmdcache
+.stylelintcache
+.prettiercache
+
+# TypeScript
+tsconfig.tsbuildinfo
+
+# Metadata Files
+CODEOWNERS
+
 # Prettier's Handlebar parser is limited and chokes on some syntax features
 # https://github.com/prettier/prettier/issues/11834
 scripts/release-post/template.hbs
-
-# We shouldn't lint statically generated Storybook files
-storybook-static

.remarkrc.json

@@ -0,0 +1,17 @@
+{
+  "plugins": [
+    "remark-preset-prettier",
+    "remark-frontmatter",
+    "remark-preset-lint-node",
+    ["remark-gfm", false],
+    ["remark-lint-fenced-code-flag", false],
+    ["remark-lint-first-heading-level", false],
+    ["remark-lint-maximum-line-length", false],
+    ["remark-lint-no-file-name-articles", false],
+    ["remark-lint-no-literal-urls", false],
+    ["remark-lint-no-undefined-references", false],
+    ["remark-lint-prohibited-strings", false],
+    ["remark-lint-unordered-list-marker-style", "-"],
+    ["remark-preset-lint-node/remark-lint-nodejs-links.js", false]
+  ]
+}

COLLABORATOR_GUIDE.md

@@ -482,31 +482,6 @@ Defining a `.vscode` configuration like this also aides browser-only development
 
 The npm ecosystem resolution and installation of `peerDependencies` installation [changed in recent versions](https://nodejs.org/en/blog/npm/peer-dependencies#using-peer-dependencies). The project documents what version of `Node.js` and `npm` to use via the [`.nvmrc` file](https://github.com/nodejs/nodejs.org/blob/main/.nvmrc). Not all contributors have tooling to automatically read this file and adhere to the correct version, however. To ensure all contributors install dependencies the same way, a local `.npmrc` file directly configures peerDependency installation behavior.
 
-### Why we don't use [`remark-preset-lint-node`](https://github.com/nodejs/remark-preset-lint-node)?
-
-The Node.js GitHub organisation owns an in-house remark preset (set of rules and plugins) that standardises the contents of Markdown files across the GitHub organisation.
-This package uses `remark` plugins such as `remark-gfm`, and it has rules such as forbidden words, maximum line-length of Markdown content, and many very specific rules.
-
-This preset is used within Node.js Development tooling itself (within `make`) and it used as a one-off script to lint the Markdown files within the `nodejs/node` repository.
-(The same preset is also used within `nodejs/node` CI).
-
-Whilst that preset has a lot of value, it is not suitable for the Node.js Website. One of the main reasons are that it inheritedly conflicts with `prettier` and with `mdx-js`,
-which causes issues from ensuring that Markdown and MDX files are correctly linted, formatted and parsed. Not to mention that these amount of rules, greatly increase the running time of ESLint.
-
-Hence, we decided to not use this preset and instead use a more minimalistic approach to linting Markdown files. Which means that we follow the default recommended `remark-lint`, `mdx-js` and `commonmark`
-linting and formatting rules, plus the formatting rules enforced by prettier.
-
-We also decided to not use `remark-gfm` as we want to support the basic CommonMark standard for Markdown files, and the default MDX standard for MDX files.
-Having that said, there's one exception, as we use [`autolink-literal`](mdast-util-gfm-autolink-literal) for transforming literal links (text) into anchor elements, which is part of the GitHub Flavoured Markdown specification.
-
-Finally, as the Node.js Website grows, we have thousands of Markdown files, meaning the more rules we add, the more time it takes to lint and format the Markdown files. And the greater the chance is
-for the standard adopted on the `nodejs/node` repository to deviate from standard spec-compliant CommonMark. The Node.js Website uses a default recommended configuration that enforces our Markdown files to be spec-compliant.
-
-It's important to mention that this repository is compatible with Markdown files from `nodejs/node` as our formatting is way less strict.
-We also have rules in-place (for example in the release blog post generation) that ensure that Markdown files that are "loaded" from `nodejs/node` are compatible when created.
-
-Also note that our goal is to fully support any Markdown file incoming from `nodejs/node` and that originates from the `remark-preset-lint-node`. Our goal is to support our fellow collaborators and to ensure that the Node.js Website is fully compatible with the Node.js project.
-
 ## Seeking additional clarification
 
 A lot of the current structure is due to retro-compatibility, keeping a simple and familiar file structure and keeping files that have historical reasons or needs.