Get rid of monaco-editor

[CGNonofr]

Following conversation on TypeFox/monaco-languageclient#546

I was thinking about it for a while also... to go even further, what we can do is:

• Stop trying to grab monaco-editor source-code at all, take everything from the vscode repo, remove all treemending logic
• Publish a new package monaco-vscode-editor-api that just exposes the same api as monaco-editor-core (which can be installed as monaco-editor:npm:@codingame/monaco-vscode-editor-api of course

The only risk/concern I see is if a library imports internal monaco-editor modules (like monaco-vim seems to do) but there is probably a solution for that

I see 3 mains pros:

• It simplifies the build process
• It allows to treeshake properly monaco-editor files (which are not treeshaken at all for the moment)
• it allows to update from VScode at anytime, no matter if monaco-editor was released or not (even if it's probably a good idea to synchronize since they test it before releasing)

It would also allows to replace createEditor by the createConfiguredEditor transparently

What do you think about it @kaisalmen?

[kaisalmen]

@CGNonofr, generally I like the idea! See the 🚀
Would that editor work with all the monaco-editor playground examples? Or would it only be the core without any extras?
Will look at your POC PR likely tomorrow. Haven't done, yet.

[CGNonofr]

What do you mean by extras? The only thing monaco-editor adds on top on monaco-editor-core are the language grammars and the intellisense for css/html/json/typescript

[kaisalmen]

@CGNonofr sorry that was poorly written.

That is the regular content of edcore.main.js to my understanding what monaco-editor-core provides (what is also stated in the monaco-languagclient README

import './editor.all.js';
import './standalone/browser/iPadShowKeyboard/iPadShowKeyboard.js';
import './standalone/browser/inspectTokens/inspectTokens.js';
import './standalone/browser/quickAccess/standaloneHelpQuickAccess.js';
import './standalone/browser/quickAccess/standaloneGotoLineQuickAccess.js';
import './standalone/browser/quickAccess/standaloneGotoSymbolQuickAccess.js';
import './standalone/browser/quickAccess/standaloneCommandsQuickAccess.js';
import './standalone/browser/referenceSearch/standaloneReferenceSearch.js';
import './standalone/browser/toggleHighContrast/toggleHighContrast.js';
export * from './editor.api.js';

The future editor will only consist of editor.all.js everything else one can be added via service overrides and default extension. If this is the case users could build everything that is shown in the monaco-editor playground and everything beyond can be added via the extension and service packages.

What I am after is: Users should regularly be able to exchange monaco-editor with monaco-vscode-editor-api when the above criteria are correct. Is that correct?

[CGNonofr]

I'm not sure to understand what you mean but the edcore.main.js if a monaco-editor only file that is already removed so I don't expect any change

[kaisalmen]

From the POV of monaco-editor : Just to detail what the actual content of monaco-editor-core is (that is the info we provide in the mlc README) and what my expectation is the of the new editor: Contents of editor.all.js minus the standalone things.

[CGNonofr]

What I am after is: Users should regularly be able to exchange monaco-editor with monaco-vscode-editor-api when the above criteria are correct. Is that correct?

Yes, that is the point. The only difference is that you can import from monaco-editor/esm modules directly and that's not the case for monaco-vscode-editor api... except some modules:

• esm/vs/editor/editor.api because some libraries import it to prevent loading monaco-editor feature
• esm/vs/editor/common/commands/shiftCommand because it's used by monaco-vim

[kaisalmen]

@CGNonofr I guess you are aware of https://www.npmjs.com/package/monaco-editor-workers
I created this package to have a builder independent utility that provides all monaco language worker as ESM and IIFE (for Firefox) bundles and can be used easily. This is no longer needed as the default-extension supply this directly, correct?

For the editorWorkerService special handling seems to be required though. Could it be beneficial to externalize the demo's getWorker function into it's own package or sub-package or is it better to supply such functionality on another level like the monaco-editor-wrapper?

[CGNonofr]

This is no longer needed as the default-extension supply this directly, correct?

Was it possible to use it already? the monaco language workers were replaced by vscode extensions a while ago here

The worker configuration can 100% be externalized, feel free to do any improvement on it :)

I'm aware of monaco-editor-workers but I don't know exactly how it works

[kaisalmen]

The worker configuration can 100% be externalized, feel free to do any improvement on it :)

I will do this. After I merged the wrapper into the mlc repo and everything works smoothly with v2