Write Webpack loader for readme.md

[fregante]

I think we’re parsing readme.md the wrong way. Instead of asking webpack to replace magic variables we parse and handle manually, we should be able to write import featuresInfo from './readme.md' and have a loader parse and keep track of the file as part of the dependency graph (as originally discussed in #3678)

We still need to “parse” refined-GitHub.ts to get the list of active features, but maybe there’s a solution to that too (separately)

[fregante]

Docs: https://webpack.js.org/contribute/writing-a-loader/#guidelines

Probably the /build/readme.loader.ts file will look something like:

export default function (source) {
  const list = /* extract feature list from `source` */
  return `
	export const featureList = ${JSON.stringify(list)}
	export const featureMetas = ${JSON.stringify(etc…)}
  `;
}

The difference with the current extraction code is that that looks for each specific feature by name, while this loader should just detect and parse all lines that include a feature name/description/screenshot.

[fregante]

The problem however is that this will no longer cause the build to fail since the build no longer looks for specific features in the file. Suggestions welcome.

Edit: found a solution: Move this check to GHA #4493

[fregante]

This would allow us to switch to esbuild instead 😃

It also has a loader-like feature: https://esbuild.github.io/plugins/#load-callbacks

But it would additionally need a custom solution for __filebasename: evanw/esbuild#1492 (comment)

[kidonng]

I actually prefer the old way of specifying feature meta. For single source of truth we can generate the README via a script, which is a lot more easier to deal with. Apparent downsides would be duplicate README template content and you will have to remember to generate it whenever you update the info...

[fregante]

which is a lot more easier to deal with

Is it?

• The readme has sections and an order, which the in-file meta never had.
• We already have the "markdown parser" so it can't be easier than that. 😃
• Markdown is easier to parse than JavaScript, the previous parser wasn't perfect.
• A generated readme means we have to "keep it in sync" when committing — it will be semi-automatic, but that means you can't just change the description in one file on GitHub.com's editor.

[kidonng]

Not am I asking to revert the whole efforts of parsing info from README, I just thought this separation feels unnatural for me, and exotic for casual contributors.

[fregante]

Not am I asking to revert the whole efforts of parsing info from README, I just thought this separation feels unnatural for me, and exotic for casual contributors.

Not sure what's exotic about writing documentation in Markdown. If anything, following some specific (parseable) format in a JS comment is exotic.

The only exotic part is importing the magic variable from '../readme.md', which happens exclusively in 2 files maybe, and new contributors won't have to ever touch it.

This would allow us to switch to esbuild instead 😃

We might also just use Parcel since it takes manifest.json as the entry point, handling everything else. I opened a PR that switches to Parcel (but requires this issue to be solved first)