search

CodinGame / monaco-vscode-api

VSCode public API plugged on the monaco editor
MIT License
208 stars 29 forks source link

Make editor api compatible with monaco-graphql #391

Closed CGNonofr closed 2 months ago

CGNonofr commented 2 months ago

Question is if it does make sense to extended those exports whenever it's needed or if there is a more general approach.

Do you have any idea of a more general approach?

github-actions[bot] commented 2 months ago

:tada: This PR is included in version 4.2.0 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket:

kaisalmen commented 2 months ago

Do you have any idea of a more general approach?

I have one idea: Could it make sense to introduce a sub-export "@codingame/monaco-vscode-editor-api/editorall" that mimics most of the content of the edcore.main.js, so people can choose a different import. You would still have the directory structure with all the required file exporting vscode content, but the exports don't look polluted. WDYT?

The real problem is that monaco-editor package is not of "type" = "module" and does not export single "features" an we have to live with that😆 With all the packages you created here, you created blue-print of how vscode could be structured in the future.

CGNonofr commented 2 months ago

Do you have any idea of a more general approach?

I have one idea: Could it make sense to introduce a sub-export "@codingame/monaco-vscode-editor-api/editorall" that mimics most of the content of the edcore.main.js, so people can choose a different import. You would still have the directory structure with all the required file exporting vscode content, but the exports don't look polluted. WDYT?

Canyou elaborate? I'm really not sure I understand what you mean and I even don't really know what to ask to clarify.

edcore.main.js is just importing monaco feature and exposing the editor api. I don't understand what you mean by so people can choose a different import

I don't understand at all what you means in the last sentence :grimacing:

kaisalmen commented 2 months ago

edcore.main.js is just importing monaco feature and exposing the editor api. I don't understand what you mean by so people can choose a different import

It does import './editor.all.js'; which again contains all the contributions that's what I am after.

I don't understand at all what you means in the last sentence 😬

I wanted to underline what a nice job you did here. 😆 @codingame/monaco-vscode-* is a blue print how a future modular / esm version of vscode could be structured. You decomposed everything into little pieces, so you can compose whatever you want scaling from a simple monaco-editor to a full vscode-web.

CGNonofr commented 2 months ago

Stop it, I will get a big head!! :grin:

It does import './editor.all.js'; which again contains all the contributions that's what I am after.

Those standalone contributions were mostly replaced by the VSCode equivalent (and mandatory with monaco-vscode-api), why are you after them?

Sorry, by last sentence, I meant the last one I quoted:

You would still have the directory structure with all the required file exporting vscode content, but the exports don't look polluted. WDYT?

kaisalmen commented 2 months ago

Those standalone contributions were mostly replaced by the VSCode equivalent (and mandatory with monaco-vscode-api), why are you after them?

It is just about filling the gaps and linking to the correct vscode code if necessary. Basically what you started without the need for all the extra exports for every single file that is currently in the package.json of @codingame/monaco-vscode-editor-api.