Optimize how external libs are handled and allow for custom languages

[stefan-lacatus]

• Adding/removing extra libs does not trigger a full worker refresh. Covers FR: Detect when addExtraLib is done processing / Permit bulk add/delete extra lib operations monaco-editor#1300 and Allow creating new languages that use the Monaco typescript features #16 (comment)
• Manual control over when the extra libs are sent to the worker via setEagerExtraLibSync and syncExtraLibs. This enables the user to do bulk updates of libraries.
• Adding a new lib with the same name as an already existing one, instead of throwing an error, will update it and send it to the worker. This can be considered a breaking change if you were relying on the error being thrown.
  Also included, the capability to define custom languages via monaco.languages.typescript.setupNamedLanguage

[trevorade]

@alexandrudima, this PR resolved an important use case for our platform: supporting client-side and server-side JS at the same time where model symbols don't overlap between the two JS flavors.

Any indication of the status of this PR?

[trevorade]

Again, this is assuming that properties don't get renamed.

[stefan-lacatus]

Not sure what you mean

[trevorade]

languageDefaults is an object literal defined with an interface with non-string keys. The TypeScript compiler may rename the keys to something else so referencing the properties with string keys isn't safe.

[stefan-lacatus]

languageDefaults is just a map we have full control over. Adding items to it is fully handled by the user, so i don't see how the compiler can interfere with that. See https://github.com/Microsoft/monaco-typescript/pull/30/files/292108c5ee680df61aa87a79319caf4713aa6e36#diff-e54df758d643734a71ab22c92c524518R243

[alexdima]

👍 Thank you!

I've only accepted a part of the PR. Please, in the future, open one PR per feature to avoid having to undo changes... Here are my changes:

• no setupNamedLanguage as that was not motivated at all and this project aims to support JS and TS, and not arbitrary other programming languages.
• removed extra lib syncing option / method and tackled via an event that runs at the next tick to accumulate multiple calls to addExtraLib
• moved the code which updates the extra libs to the workerManager

[trevorade]

@alexandrudima, thanks for accepting this!

• no setupNamedLanguage as that was not motivated at all and this project aims to support JS and TS, and not arbitrary other programming languages

I was interested in this PR to allow Monaco to differentiate between browser-style JS and server-side JS (i.e., NodeJs) for extra libraries and symbol sharing between models. This is a use case that I'm currently supporting in my usage of Monaco by having to dispose of all the extra libraries + models of the other JS flavor and then adding the correct extra libraries and recreating the correct models (with the restored view state but, unfortunately, losing the undo state as that is not restorable).

setupNamedLanguage was a cleaner solution to this because it permits switching between browser-side and server-side JavaScript source files without any hacking necessary.

[alexdima]

Currently, that is outside the scope of this project.

My recommendation in these cases is to fork this project and then pick up directly monaco-editor-core from npm (which is the monaco editor minus languages), and then add monaco-languages, monaco-html, etc. This can be done manually, or by reusing the very same scripts through which the monaco-editor is published.

This is relatively easy to do by editing the metadata.js file in the editor repo (https://github.com/Microsoft/monaco-editor/blob/master/metadata.js) and then pointing that to your own fork of monaco-typescript..