Reduce churn

[wooorm]

Hi folks! 👋

I just came back to this repo after a while, going through issues, PRs, dependency updates, etc, and this may just be me but to me it feels like there’s a bit much churn to maintain this repo:

• Building is long: takes about 5 to 8 minutes for a CI job to finish; not too important, but it takes 2:30 to install dependencies, between 2 and 4 minutes to store a cache version of them, …
• GH CI sometimes randomly fails: for a PR pushed from the repo, there are 18 CI builds done 2 (PR + Push) * 3 (macos, windows, ubuntu) * 3 (node 8, 10, 12). Looking through the renovate PRs, about 1/3rd of them randomly failed.
  Also seems that GH runs up to ± 6 builds at the same time, so in total it takes 15m-20m to check everything
• Deps are completely version locked in package.json, which I think makes sense for the MDX library, but it creates noise for dev-dependencies, examples, and the site: I find the current list of open PRs and list of commits pretty unreadable
• Our tests are based on fixtures, which is fine, but if something meaningless changes it causes a failure

---

While tooling is great (hey, I spend all my time building tools), and maybe I’m just horribly out of touch with what modern development is supposed to look like, I think it would help maintainers and contributors if we could make the repo simpler and builds faster and less fragile! A couple of ideas:

• Don’t build on macOS: it’s mostly similar to ubuntu and I believe most maintainers of MDX have a mac
• Don’t build on Node versions except for the outliers (so at the moment, do test on 8 and 12, but not on 10)
• Marie Kondō dev-dependencies / tools
• Move remark-* stuff to the @remarkjs org
• Figure out if we can configure renovate better
• Rework tests! (this is a big thing that should be discussed somewhere else)

[ChristianMurphy]

but it takes 2:30 to install dependencies

npm 7 may help, v7 adds support for workspaces which was previously one of the main draws for yarn.
Testing locally a clean yarn install:

$ rm -rf **/node_modules
$ node --version
v15.1.0
$ yarn --version
1.22.10
$ yarn

takes around 59-68 seconds.
while a clean npm install

$ rm -rf **/node_modules
node --version
v15.1.0
$ npm --version
7.0.8
$ npm ci

takes between 42 to 48 seconds.

I expect the results would be even more pronounced on Github Actions.

between 2 and 4 minutes to store a cache version of them

Cache time may be mostly unavoidable

but, tying into:

Deps are completely version locked

Allowing version ranges could allow the version resolver some more flexibility in de-duplicating.

Don’t build on macOS: it’s mostly similar to ubuntu and I believe most maintainers of MDX have a mac

I'd push back on this a bit, while uncommon, there can be some MacOS specific issues.
I've been leaning more towards T shaped testing lately

	MacOS	Linux	Windows
Latest	✔️	✔️	✔️
LTS		✔️
LTS 2		✔️

Which tests across all OSes, but only tests previous Node versions in a specific OS.

[ChristianMurphy]

Marie Kondō dev-dependencies / tools

Do you have some specific tools in mind, which don't spark joy anymore?

Move remark-* stuff to the @remarkjs org

👍

[ChristianMurphy]

Figure out if we can configure renovate better

Renovate has some pretty powerful configuration options.
Do you have some particular ideas in mind?
https://docs.renovatebot.com/noise-reduction articulates some common techniques for noise reduction.

Another which lines up with possibly loosening:

Deps are completely version locked

would be ":preserveSemverRanges"

[wooorm]

solved, actions are much faster, the repo is installable, etc.