Big name points towards ambitions not current features which are is:

• Preview

First, you'll have to install VSCode. Then you can run:

git clone [email protected]:Gregoor/mdn-writer-toolbox.git
cd mdn-writer-toolbox
code .

This will open the project in VSCode. There you can press F5 which will compile the extension and open up a new instance of VSCode with the extension running inside of it. Navigate to mdn/content to see the preview in action.

Whenever a file is opened, check if it looks like MDN content, meaning:

• .html/.md file
• has a root with a package.json in one of its parent folders from which a @mdn/yari/content/document.js can be imported)

If it does, run npm run start from the root with a random server port and once that server is running, open a webview panel in the second column to show the rendered page.

• Should it ship with yari instead of reusing what's there?

  I think not because it allows having multiple content versions, with different yari's lying around. And newest yari is not necessarily compatible with older content. Plus this means we have to update the extension less often.
  But it's worth thinking through again with another mind than mine!

• Why is the preview not more instant?

  This is somewhat related to the previous item. The extension currently requires the file to be saved so that yari's server picks it up. And then we trigger a reload.
  I think a more solid, less server-y approach would be to use some Yari API to just render out a document, without chrome (header, footer, etc.) and throw that HTML directly into the webview panel, while also maintaining the scroll position. That seems a lot harder to do though, so I didn't.

• How should it select which port to run on?

  Currently it just tries a random port, but there is a chance of collision here. Should probably just put rethrow the dice in that case?

• Where should the Preview open?

  Right now it just always opens in the second column. Also it will re-open again when you close it. I think both of those are wrong, they disrespect user choice. The right thing to do is probably something like:

  • auto-open preview, until user closes it. Then only go back into auto-open mode when user runs a the reopenPreview command
    • or even better, make it configurable whether it should auto-open
  • open in the second column by default but make it configurable to open somewhere else (first column, as tab, etc.)

• CI

  It should publish a new version for all changes on main into the VSCode Extension Marketplace