Doesn't work when run from the svelte repl (or any other browser environment)

I’m trying to run mdsvex from a browser environment but it seems to be failing loading the fs module.

This trivial example fails the svelte repl:

<script>
	import { mdsvex } from "mdsvex";
	let compiled = mdsvex.compile("Hello *world*")
</script>

{compiled}

[pngwn]

It is half working

I’ve created a working browser build with a few caveats:

• syntax highlighting doesn’t work (although you could pass a browser friendly one in)
• layouts don’t work

There are two builds, an ESM build and a UMD build. The ESM build should be used when you want to import mdsvex or when bundling. The UMD version is good in a worker environment with importScripts as it will attach itself to the global namespace (window or worker global scope)

They need to be imported via a deep path (i haven’t added export maps to mdsvex yet):

• browser ESM - mdsvex/dist/browser-es.js
• browser UMD - mdsvex/dist/browser-umd.js

it isn’t fully working

The process.browser build time replacement replacement has been broken for a while because I changed the syntax a little (in order to type the custom process object in TS), I fixed that but it isn’t fully working.

The layouts are never going to work with the current implementation because they rely on a. file system and there is no way to inject a virtual FS for them to use. This will require a more significant refactor and I’ll take care of it in the future. This also doesn’t work in the mdsvex REPL.

The code highlighting is a bit more interesting.

This does work in the mdsvex REPL because, as @DougAnderson444 mentioned, I have a custom build. That custom build replaces requires with importScripts calls (which exists in a worker environment), when loading language metadata. However, switching between require and importScripts isn’t a great solution because importScripts only exists in a worker and not in a non-worker browser environment. In a normal browser environment, dynamic import (import()) is probably a better choice. Ideally I could use dynamic imports everywhere but browser support for module imports (and dynamic imports especially) is a little patchy in workers.

The other issue is that require and importScripts are both synchronous while dynamic imports are asynchronous. This means that doing a straight swap base don some build flag, or even at runtime isn’t going to work that well either. The control flow would need to be different as promises are a disease that run throughout the entirety of your program when you start using them.

if I do go down that route, I’ll probably need to promisify require and importScripts for it to be consistent with import(). I could also just use the dynamic import in node, as they are well supported.

I haven’t fully decided the best way to handle this. I’ll probably promisify anything synchronous and add some flags/ checks to figure our the different envs, for the time being. Non-node environments will still need a custom build until I can rewrite this properly, as mdsvex uses a bunch of node built-ins.

Anyway, this should be working with the above caveats in mdsvex@0.9.5. I put together this example REPL.

[pngwn]

The highlighter will change to shiki in v1. This has a functional browser build, I’ll just need to make sure there isa. simple way to add different languages, themes, generate the correct css, support themes.

Layout loading will be the other challenge, I’ll need to ensure the way layouts are accessed is injected rather than relying on the presence of a FS.