You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of posting, JupyterLab 3 is still a release candidate, but is a pretty compelling way forward, and already pretty easy to develop against pip or conda. As #10 adds a serverextension to handle the .wasm mime type junk, it would be a relatively small step to move to a pip install-and-there-you-go end user experience.
migrate to a jupyter_server (vs notebook) extension...
I haven't done this before, but it can't be that different
add the labextension build stuff, dumping into src/jupyterlab_markup/static
redo the build plumbing
source the version (and other package information) only from static/package.json
I'm a fan of doit for keeping the package in a releasable state from a single package
Because a big part of #10 is to make this extensible, it would still be important to do npm releases, so that others can get at the Token to make extensions with additional markdown-it plugins.
The text was updated successfully, but these errors were encountered:
As of posting, JupyterLab 3 is still a release candidate, but is a pretty compelling way forward, and already pretty easy to develop against
pip
orconda
. As #10 adds a serverextension to handle the.wasm
mime type junk, it would be a relatively small step to move to apip install
-and-there-you-go end user experience.Some concrete steps on top of #10:
jupyter_server
(vsnotebook
) extension...labextension build
stuff, dumping intosrc/jupyterlab_markup/static
static/package.json
doit
for keeping the package in a releasable state from a single packageBecause a big part of #10 is to make this extensible, it would still be important to do
npm
releases, so that others can get at theToken
to make extensions with additionalmarkdown-it
plugins.The text was updated successfully, but these errors were encountered: