I believe the examples label has been added by mistake. I don't think I can remove it.

If you are using pnpm, you can patch the monaco-editor.
For example, here is my integration of monaco-editor with next.js: https://github.com/Chenalejandro/next.js/tree/add-monaco-editor-example/examples/monaco-editor. To work around turbopack,

1. run pnpm patch [email protected] (or adjust to the version you are using)
2. open the directory returned by the previous command
3. open the file esm/vs/base/common/worker/simpleWorker.js and add the following four lines:

         if (isESM) {
             const url = FileAccess.asBrowserUri(`${moduleId}.js`).toString(true);
+            if (process.env.NODE_ENV === "development") {
+                throw new Error(`No RequestHandler!`);
+                return;
+            }
             return import(`${url}`).then((module) => {

4. open the file esm/vs/editor/common/services/editorSimpleWorker.js and add the following four lines:

             else {
                 const url = FileAccess.asBrowserUri(`${moduleId}.js`).toString(true);
+                if (process.env.NODE_ENV === "development") {
+                    reject();
+                    return;
+                }
                 import(`${url}`).then(onModuleCallback).catch(reject);
             }

5. run pnpm patch-commit YOUR_MONACO_EDITOR_PATH, where YOUR_MONACO_EDITOR_PATH is the path returned by step 1

The only issue is that the editor will not have syntax highlighting when running next.js in dev mode.

The turbopack team said that they will be migrating the most popular webpack plugins to turbopack once they reach stable, so lets hope that monaco-editor-webpack-plugin will get the same treatment.

They don't have to add support for plugins, they just need to relax the rewriting rule for truly dynamic imports. It should not be failing for something that can be resolved at runtime (maybe emit a warning but not hard stop error), it's on me to provide the adequate workaround. It's just a matter of mapping entry points to chunks. That's all there's to this. I've done this before but here I find Turbopack missing a critical feature. It's just overly zealous about rewriting some imports.

If you are using pnpm, you can patch the monaco-editor. For example, here is my integration of monaco-editor with next.js: https://github.com/Chenalejandro/next.js/tree/add-monaco-editor-example/examples/monaco-editor. To work around turbopack,

1. run pnpm patch [email protected] (or adjust to the version you are using)
2. open the directory returned by the previous command
3. open the file esm/vs/base/common/worker/simpleWorker.js and add the following four lines:

         if (isESM) {
             const url = FileAccess.asBrowserUri(`${moduleId}.js`).toString(true);
+            if (process.env.NODE_ENV === "development") {
+                throw new Error(`No RequestHandler!`);
+                return;
+            }
             return import(`${url}`).then((module) => {

4. open the file esm/vs/editor/common/services/editorSimpleWorker.js and add the following four lines:

             else {
                 const url = FileAccess.asBrowserUri(`${moduleId}.js`).toString(true);
+                if (process.env.NODE_ENV === "development") {
+                    reject();
+                    return;
+                }
                 import(`${url}`).then(onModuleCallback).catch(reject);
             }

5. run pnpm patch-commit YOUR_MONACO_EDITOR_PATH, where YOUR_MONACO_EDITOR_PATH is the path returned by step 1

The only issue is that the editor will not have syntax highlighting when running next.js in dev mode.

The turbopack team said that they will be migrating the most popular webpack plugins to turbopack once they reach stable, so lets hope that monaco-editor-webpack-plugin will get the same treatment.

I opted to do this instead:
if(process.env.TURBOPACK) instead of if(process.env.NODE_ENV === 'development')

This way, when I want to work with monaco editor, I can run without --turbo.
But when not working with --turbo, things won't crash and burn.

Hey! Having the same issue. Any updates or workarounds other than patching monaco-editor?

Could you share a full reproduction repository?

I.e. @monaco-editor/react works with Turbopack:

"use client";

import Editor from "@monaco-editor/react";

export default function IDE() {
  const handleSubmit = async () => {};

  return (
    <div className="flex justify-center items-start pt-10 h-screen">
      <div className="w-full max-w-4xl p-4 border">
        <form action="#" onSubmit={handleSubmit}>
          <div className="">
            <label htmlFor="comment" className="sr-only">
              Add your code
            </label>
            <Editor
              height="50vh"
              defaultLanguage="javascript"
              defaultValue='Deno.serve(req => new Response("Hello!"));'
            />
          </div>
          <div className="flex justify-between pt-2">
            <div className="flex items-center space-x-5"></div>
            <div className="flex-shrink-0">
              <button
                type="submit"
                className="inline-flex items-center rounded-md bg-indigo-600 px-3 py-2 text-sm font-semibold text-white hover:bg-indigo-500"
              >
                Run
              </button>
            </div>
          </div>
        </form>
      </div>
    </div>
  );
}

@timneutkens https://github.com/GreenBabyBorn/monaco-nextjs-turbopack

I don't know that it does. The problem really is with the way Next takes control over the rewriting of imports without leaving you with any option to bail. @monaco-editor/react is facilitated by @monaco-editor/loader which in turn has one or two things to say about getting going, see here.

All I want, is to be able to use Monaco directly without libraries and workarounds. For that to be possible I need to be able to tell Next to not touch the import that does the bootstrapping for Monaco. I'm perfectly happy with vendoring the libraries. In my particular situation, a CDN is also out of the question.