[Bug] marked.Renderer is not a constructor

[gongtiexin]

trafficstars

Reproducible in vscode.dev or in VS Code Desktop?

• [X] Not reproducible in vscode.dev or VS Code Desktop

Reproducible in the monaco editor playground?

• [X] Not reproducible in the monaco editor playground

Monaco Editor Playground Code

No response

Actual Behavior

I try to export directly

import { marked } from 'monaco-editor/esm/vs/base/common/marked/marked.js';

marked is empty object

Expected Behavior

No response

Additional Context

No response

[hediet]

I wonder if this is a bundling issue.

[mjbvz]

@alexdima Do we allow Monaco users to load our internal files like this?

[gongtiexin]

I load monaco-editor by monaco-editor-webpack-plugin. Then the error "marked.Renderer is not a constructor" is reported. So I want to try to import the marked.js file separately, and the last imported marked is an empty object. I don't know if it is a problem with the packaged build configuration.

[lwdgit]

The same to me, here is screenshot.

[lwdgit]

export var marked = (__marked_exports || exports);

The same to me, here is screenshot.

fixed by change marked.js:

- let __marked_exports = {};
+ let __marked_exports = typeof define === 'function' && define.amd ? {} : null;

[miamagana]

Hello @mjbvz, I have been looking for several weeks for a workaround to solve this issue when loading monaco-editor by ESM and found this issue that was closed some years ago, can this be a regression?.

I would appreciate any workaround to solve this issue, I am not loading monaco with the webpack-plugin as @gongtiexin above, but I can confirm that the issue is still present without using the plugin.

I have tested different monaco-editor versions from v0.19.3 to v.0.33 and the issue is reproducible since v31.0 at least. I am exposing a commonjs library using webpack and the AMD is not an option because it would require a re-write of the whole project.

Let me know if I can help with something in order to get this resolved, or if there are any workaround available for this!

[bockj]

@miamagana I had the same problem, using monaco in an (inhouse) library bundled as commonjs using webpack (without the plugin) and the library itself in included is several react apps.

I could "fix" the issue for me in [email protected] by changing marked.js as

-export var marked = (__marked_exports || exports);
+export var marked = exports;

at the very end of the file.

[miamagana]

@miamagana I had the same problem, using monaco in an (inhouse) library bundled as commonjs using webpack (without the plugin) and the library itself in included is several react apps.

I could "fix" the issue for me in [email protected] by changing marked.js as

-export var marked = (__marked_exports || exports);
+export var marked = exports;

at the very end of the file.

Hello! Thanks for your answer, this fix is by editing the marked.js file in monaco-editor package, right? Meaning that everytime you install the dependencies or try to do a clean build, you will need to modify it again.

If so, it's not ideal but at least is a way of staying up to date, many thanks!

[bockj]

@miamagana Yes, you have to edit it in the package directly. I'm aware of two ways how to make this workaround permanently:

• You can automate this patching by using https://github.com/ds300/patch-package . I've used it in the past and it worked quite well.
• You publish the patched monaco-editor under a separate name (e.g. @mycompany/monaco-editor-workaround) and reference it via an alias in you package.json:

dependencies: {
 "monaco-editor": "npm:@mycompany/[email protected]",
}

instead of

dependencies: {
  "monaco-editor": "0.33.0",
}

The second option is really nice if you have a self hosted package registry, otherwise I would use the first one.

[miamagana]

@miamagana Yes, you have to edit it in the package directly. I'm aware of two ways how to make this workaround permanently.

Thanks a lot for your answer @bockj! It totally makes sense to workaorund it until monaco officially fixes this!

[graphemecluster]

As mentioned in https://github.com/microsoft/monaco-editor/issues/2966#issuecomment-1165439620, the fix above doesn't work for my case (I'm using Parcel). I believe that the correct fix is to remove everything between // ESM-uncomment-begin and // ESM-uncomment-end:

@@ -8,17 +8,8 @@
  * DO NOT EDIT THIS FILE
  * The code in this file is generated from files in ./src/
  */
 
- // ESM-uncomment-begin
- let __marked_exports = {};
- (function() {
-   function define(deps, factory) {
-     factory(__marked_exports);
-   }
-   define.amd = true;
- // ESM-uncomment-end
- 
  (function (global, factory) {
   typeof exports === 'object' && typeof module !== 'undefined' ? factory(exports) :
   typeof define === 'function' && define.amd ? define(['exports'], factory) :
   (global = typeof globalThis !== 'undefined' ? globalThis : global || self, factory(global.marked = {}));
@@ -2942,9 +2933,4 @@
 
   Object.defineProperty(exports, '__esModule', { value: true });
 }));
 
- // ESM-uncomment-begin
- })();
- export var marked = (__marked_exports || exports);
- // ESM-uncomment-end
- 

This also fixes #2966 at the same time.

[graphemecluster]

Info: the change was introduced in https://github.com/microsoft/vscode/pull/141429. Better opening a issue in the VSCode repo.

[Ozzadar]

This bug affects our project as well. The comment https://github.com/microsoft/monaco-editor/issues/3035#issuecomment-1165455990 makes everything work as intended as well.

[hediet]

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding, and happy coding!