Hi there....
I am currently stuck on this particular conundrum and can't seem to find a workaround.
The premise is that we have a node with two or three multi-line text editor inputs that will contain some user-editable javascript similar to the way the function block currently operates. The catch is that the context in which the script gets applied / executed is completely different to the one used by the function node- it does not make any node-red (RED, util, flow, global, context etc etc) or browser (window, document, etc) specific references but instead references custom properties, functions and types we've built for the node specifically- eg: for a the Accounting Function Node it might be:
let account = accounts.getAccount(msg.acocuntID);
// do something with the account here.
where accounts is a type with a getAccount function declared on it that might fetch an account from the accounting system.
Is there a simple way of removing / restricting what gets added to the mode specified in the RED.editor.createEditor({.....}) call in terms of validation / auto-completion / intellisense or is my only real option to pull in an untainted instance of monaco via an iframe and embedding it in the node editor?
Iirc, createEditor returns an instance of the editor you can manipulate. The createEditor function does not provide a mechanism for applying custom completions itself. Also, Monaco is present in the window object (so importing a copy seems superfluous.
However , a means of providing options in the RED API would be the ideal in case Monaco ever changes its APIs (which it has done in the past). A plan and a PR to the core node red would be appreciated but realise this wouldn't help you in the short term.
I think the problem here is that monaco's languages exist in a type of "global context". Any changes such as registering another compilationitemprovider for javascript will result in in all javascript editors now applying that specific compilationitemprovider. The way around this is to declare a new language for the purpose: such in my previous example: accounting_jay_esh and then selectively reuse components defined for the javascript language definition from monaco.
The advantage of going this route is that you effectively start off with a blank slate and gradually add parts- it also means that you can filter out suggestions from the javascript that you don't want while adding custom ones.
I manged to get a proof of concept going, now I just need to tidy it up and package it for easy reuse.
Its probably worthwhile adopting a similar approach for the function node as well: That way obscure functions and packages like "MIDIAccess" (which is part of the web api) can be filtered out.
