A guide for forking and extending monaco-typescript is needed, OR options to add code wrapper

Closely related: https://github.com/microsoft/monaco-editor/issues/1426

monaco-editor version: 0.18.1

So there is a good amount of issues that require more peculiar additions to monaco-typescript, mainly wrapping code in a function, in a JS object, for changing typing context, and for injected, user-defined code. In these cases, monaco.languages.typescript.*Defaults.addExtraLib is not enough, as seen in #1452, #45, #1439, #170.

Particular use cases include:

• educational software with input fields in code blocks, where uneditable code becomes decorations for monaco-editor and a wrapper for monaco-typescript;
• editors for functions that are members of classes and other objects, where this does not point to globalThis, e.g. in game editors for in-game entities, HTTP request editors, for any other code that comes from an end-user of a framework;
• editing json-like objects;
• probably, making of inline inputs, like in Chrome/FF dev tools while editing HTML tags.

As an end-user, it seems impossible to make such changes to monaco-typescript (due to not having required competence in monaco/vscode/typescript development). The expected result is that a version of monaco-vscode wraps input code in another code, returning correct positions for markers and such, and successfully embeds into monaco-editor while preserving syntax highlighting (this is pointed out separately as monarch tokenizer is not a part of monaco-typescript, and bringing the tokenizer to a new language mode is not obvious).

All the issues above surely have a solution, but end-users require docs to solve them.

---

Alternative: adding options for monaco.languages.typescript.*Defaults that will allow wrapping input code in a predefined structure.

[spahnke]

@guillaume86 Yes, there have been improvements if you don’t require to be able to see that function stub in the editor.

Building off of https://microsoft.github.io/monaco-editor/playground.html#extending-language-services-configure-javascript-defaults you can set to ignore the diagnostic that reports top-level return statements as an error and then just provide the declaration for your function parameters as an extra lib to get code completion and types for them. The diagnostic code to ignore can be inferred from the error message in the editor.

monaco.languages.typescript.javascriptDefaults.setDiagnosticsOptions({
    noSemanticValidation: false,
    noSyntaxValidation: false,
    diagnosticCodesToIgnore: [/* top-level return */ 1108]
});

monaco.languages.typescript.javascriptDefaults.setCompilerOptions({
    target: monaco.languages.typescript.ScriptTarget.ESNext,
    allowNonTsExtensions: true
});

var libSource = `
/** The first parameter */
declare const param1: number;
/** The second parameter */
declare const param2: number;
`
var libUri = 'signature.d.ts';
monaco.languages.typescript.javascriptDefaults.addExtraLib(libSource, libUri);
// When resolving definitions and references, the editor will try to use created models.
// Creating a model for the library allows "peek definition/references" commands to work with the library.
monaco.editor.createModel(libSource, 'typescript', monaco.Uri.parse(libUri));

monaco.editor.create(document.getElementById('container'), {
    value: "return param1 + param2",
    language: 'javascript'
});

[CosmoMyzrailGorynych]

Sadly this does nothing about the passed arguments, or expected types, or of what this is. Well, you can mimick arguments, but you can’t change the type of this in this way.