Support mjs plugins

In the documentation for plugins it shows that you can write plugins by exporting a Plugin interface.

Inconsistent documentation for plugin mjs

First, the documentation shows Plugin interface with ESM, but immediately below the example shows module.exports = definePlugin which is CommonJS and seems inconsistent.

Error with plugin mjs

Also, I have tried implementing this using ESM, please see a minimal test case at:

https://github.com/fulldecent/github-pages-template/tree/c2c394068d17bd6a939ba173a035dcb2183ccf33

and this produces errors about FileSystemConfigLoader.loadFromFile failing to load the plugin.

changed title from Support mjs pluggins to Support mjs plugins

Ah yes, that would be related to #125 (closed). The examples listed assumes you transpile to CJS right now.

However now that the API is async (since v8.0.0) it would be possible to start supporting loading configuration files (and in turn plugins etc) with native ESM support.

This would mean to implement a Resolver using import(..) instead of require(..). It would most likely require some additional internal changes to allow the resolver to be async as well but shouldn't be too much of an issue any longer.

Help is welcome, if possible. It is a high priority of mine though but I've been working on this from the other end, getting the API to support async calls.

Thank you for the breakdown! I am reviewing now and this is a bit over my head. I recognize the things that are a priority for us:

• FileSystemConfigLoader works with .mjs plugin and .mjs rules.
• Documentation supports .mjs plugins and .mjs rules (preferably as default, as consistent with rest of docs)
• Transpiling is not necessary, everything works in the context like https://github.com/fulldecent/github-pages-template/tree/c2c394068d17bd6a939ba173a035dcb2183ccf33

And I'll just add this even though it is out of scope:

• Rules can run asynchronously, for example our rule which checks broken links, such as in https://github.com/fulldecent/github-pages-template/

Our team would use this to publish https://github.com/fulldecent/github-pages-template/ which will be the new opinionated default for everybody using GitHub Pages, recommending them to use html-validate.

---

At the moment I found a workaround for our build testing. This involves building around the filesystem config loaded. It means that running html-validate from the command line (and all the great tool integration (like VS Code) that brings) will not work for now.

Implementation at:

https://github.com/fulldecent/github-pages-template/commit/ca7c5ca34a1b20f3c35f6f2b9c60bb8c0481598b

mentioned in issue #232 (closed)

mentioned in commit 40aa30b8

mentioned in commit 15774901

mentioned in commit c318b04b

mentioned in commit 81b47770

mentioned in merge request !1070 (merged)

mentioned in commit 4fcc03da

closed with commit 81b47770

mentioned in commit 0caaf450

This issue has been resolved in version 9.0.0

The release is available on:

• npm package (@latest dist-tag)
• GitLab release

Your semantic-release bot

mentioned in merge request try-online!172 (merged)

mentioned in merge request html-validate-vue-webpack-plugin!158 (merged)

mentioned in merge request cypress-html-validate!198 (merged)

mentioned in merge request html-validate-jest-snapshot!140 (merged)

mentioned in merge request vue-cli-plugin-html-validate!80 (merged)

mentioned in merge request demo!136 (merged)

mentioned in merge request example-plugin!106 (merged)