I created #16 as a test that the build succeeds. It does, so it must be an issue with your local environment.

Did you use a clean working directory? This should work:

git switch main
git clean -xdf
git fetch
git reset --hard origin/main
npm install
npm pack  # Or npm publish

This will generate the npm package, and upload it as a build artifact.

A new relase would be great! The invalid PriorityQueue was causing warnings for me, but somehow not errors.

I totally forgot about this one myself. Perhaps I should update dependencies even further.

Sorry, I saw the notification for this, but forgot about it.

I have integrated this library in a project, but I don’t use it a lot myself. It’s good to report such regressions if you suspect them.

After your last comment, my guess is it might have been a caching issue? The old version was cached, but not the new one. I’m just guestimating though.

Right, those are all good points.

It makes sense to make this opt-in, I imagine an option named allowAsyncComponents.

This will also break editor support, not because of React or MDX, but because of the same reason async components aren’t supported in TypeScript (https://github.com/microsoft/TypeScript/issues/21699).

I personally don’t need this right now, it’s just an idea I had. We can wait until someone has a real use case.

Initial checklist

• [X] I read the support docs
• [X] I read the contributing guide
• [X] I agree to follow the code of conduct
• [X] I searched issues and couldn’t find anything (or linked relevant results below)

Problem

React server components can be asynchronous. It would be nice if MDX content supports this too.

# Hello visitor

This page has been visited {await Promise.resolve(42)} times

Solution

If an await expression is detected, mark _createMdxContent as async.

Alternatives

We could not support it :shrug:

MDX 2 supports remark, rehype, and recma plugins. I think this issue can be closed?

My goal was to fix the PriorityQueue import in src/graphlib/alg/dijkstra.js.

I noticed TypeScript was used to generate type definitions, but it wasn’t configured properly. So I decided to fix that, whilst at it. The generated type definitions have been removed. They are now generated while packing.

There were some type errors that were easy to fix, but some require a bit more effort and domain knowledge. The low hanging fruits have been fixed, other issues have been handled using @ts-expect-error comments.

What your screenshot shows is the generic Monaco editor error meaning it failed to load the worker. There’s an actual error too, saying something about document being undefined. This is because document doesn’t exist in web workers. I’m unable to screenshot this, because Stackblitz is being flaky.

Your options are to:

1. Alias decode-named-character-reference to the web worker compatible export, like in https://github.com/remcohaszing/monaco-unified/blob/main/examples/demo/webpack.config.js#L18-L20
2. Make vite use the worker condition. This means it will apply to all imports though. I haven’t really seen negative effects of this myself.

   import { defineConfig } from 'vite';
   
   export default defineConfig({
     resolve: {
       conditions: ['worker']
     }
   })
   

3. Upvote https://github.com/vitejs/vite/issues/7439

Perhaps this project should define an FAQ, like https://github.com/remcohaszing/monaco-yaml#faq. I think this issue you can would fit in there.

fix: tests hanging on windows

Fixes #138 (hopefully)

2.2.3

Merge pull request #188 from microsoft/fix/windows-stdout-hang

fix: tests hanging on windows

Merge branch 'main' into cli

Personally I’m not a fan of relying on a framework-specific plugin for your bundler, so I recommend to use the method using MonacoEnvironment. However, if another method works for you, I’d say go with that.

Some people run into problems because they load the editor from a CDN. Some people aren’t even aware, because a wrapper library like @monaco-editor/react does that for them.

Also it’s important that a model and its uri represents a file on a (virtual) file system. You can’t create the same file twice. Also disposing an editor doesn’t dispose its model. I don’t think you’re running into this, but it’s something you should understand and pay attention to.

You seem to be combining two conflicting solutions. One using MonacoEnvironment and worker-loader, and one using monaco-editor-webpack-plugin. You should remove one of them.

Also you mentioned “to Mention I use seperate instances of monaco editor but always destroy them before launching a new one”.

What do you mean by that? Could you share the code?

Could you properly format your markdown? You reference non-existent issues, did you mean to reference external issues? Just use the full URL then. Also your code blocks are unreadable like this, please use actual code blocks, like this:

```js

```

I suggest to follow a markdown toturial to learn how to format content on GitHub, i.e. the commonmark tutorial.

v1.0.51

Maybe it would also be good to switch the default module compiler option to node16. This is fairly impactful to users, but it is the most correct value in most cases. I believe many users are still not even aware of this option, causing packages to be stuck on not supporting it at all.

fix: add default platform in resolveCliPathFromVSCodeExecutablePath to match docs

Fixes #183

2.2.2

Merge pull request #184 from microsoft/system-default-platform

Add default for platform in resolveCliPathFromVSCodeExecutablePath to match docs

Merge branch 'main' into cli