-
Hi MyST Markdown/JupyterBook team, I am writing a Myst Plugin which I would like to use in The Turing Way. We would like to support others using and contributing to the plugin, and keep the plugin code independent of the book contents. It would be great if it could be installed as a dependency, in a similar way to Sphinx extensions for JB1. Is there a convention for how to do this? (I'm not familiar with packaging Javascript). And additional complication, my plugin has a dependency on |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 3 replies
-
Hey @JimMadge We don't have a strong standard on this. I created an example for a JS plugin that uses It's pretty simple to adapt that to TypeScript. Curvenote have some examples of compiling TypeScript plugins, which are published to NPM. I'd be tempted not to push for NPM publishing up-front, because it's more to handle (tokens, etc) than just pushing a release artifact. |
Beta Was this translation helpful? Give feedback.
-
Hi @JimMadge Just to extend on @agoose77's examples: The simplest js plugin can be a simple esm module, requiring no packaging: e.g. https://github.com/myst-ext/myst-ext-lorem/blob/main/src/lorem.ts other lightweight bundler choices:
As the plugin can be loaded from any URL, you can choose to gather/host plugins for your community anywhere. |
Beta Was this translation helpful? Give feedback.
-
This question and the answers from @stevejpurves and @agoose77 nerd-sniped me into improving our plugin docs, PR is here :-) |
Beta Was this translation helpful? Give feedback.
Hey @JimMadge
We don't have a strong standard on this. I created an example for a JS plugin that uses
esbuild
to bundle the plugin and its dependencies into a single file, and released on GH releases: https://github.com/myst-examples/js-pluginThis plugin can be consumed by URL from its release endpoint:
It's pretty simple to adapt that to TypeScript.
Curvenote have some examples of compiling TypeScript plugins, which are published to NPM.
I'd be tempted not to push for NPM publishing up-front, because it's more to handle (tokens, etc) than just pushing a release artifact.