Publish multiple libraries

[CGNonofr]

Issues:

• textmate worker seems broken
• npm publish removes the node_modules folder from the main package

based on #184

fix #178

The problem: there is a single package that have all possible dependencies, even those you won't need because you only need the basics
Bigger problem: some dependencies can't be installed on some envs (windows-process-tree on windows?)

The idea:

• Make the main package only depend on monaco-editor
• Publish splittable stuff in other packages:
  • New ext host server
  • All default extensions
  • Both Rollup plugins
• Create meta packages for each service-override: it just imports the monaco-vscode-api export but declares the required dependencies

121 packages published in version 1.81.8-next.1 (not working yet)

[kaisalmen]

@CGNonofr wow, 121 packages. I like the overall idea, but maybe we can tweak it a bit further.
Couldn't you create one default-extensions package with separate sub-exports. Then treeshaking (end-user/application) should remove the unneeded dependencies even if they are declared in the package.json, right? Or will this not work and we end up where we are with one big package again? This would at least cut down the amount of packages dramatically. WDYT?

[kaisalmen]

@CGNonofr default-extensions was a bad example, because they don't have different dependencies, but the approach works with the services. When I bundle monaco-languageclient with conditional imports, I get separate files for the "optional"/conditional things that are not required to work (for example done here: see vite config, js bundle description and html bundle verification).
A potential target package list could be:

• main
• rollup-extension-directory-plugin
• rollup-vsix-plugin
• server
• service-overrides (with sub-exports)
• default-extensions (with sub-exports)

Separate packages for the services could be useful to make the services inter-dependencies clear (what is not there, yet btw), but I think they are not required.

[CGNonofr]

• I don't think there is any reason for the rollup plugins and the server to not be published as a separated packages
• I think each extension should be on a different package because almost nobody needs more than a few of them, and some of them are really heavy, especially the language feature ones
• The idea of publishing each service override as a package is that some of them have specific heavy dependencies (like textmate) even though they are just meta packages not containing any code. Only a few have dependencies but having a separate package for some and not for others would be confusing

I'm aware than unused exports won't be included in the bundle if they are not used but that's not my only concern: they still need to be downloaded/updated and by doing so we preserve bandwidth and storage

Do you thing that's an issue to have many packages?

I'm also aware that monaco-languageclient would probably depend on all service overrides, but that's maybe something that can be improved

[kaisalmen]

I don't think there is any reason for the rollup plugins and the server to not be published as a separated packages

Yes, I agree, they should be published as separate packages. That's why I listed them as separate bullets. 😊

I think each extension should be on a different package because almost nobody needs more than a few of them, and some of them are really heavy, especially the language feature ones

One package for all default-extensions with specific exports is fine, I think. If you look at the codingame npm overview it is kind of polluted now 😉 https://www.npmjs.com/search?q=%40codingame

Only a few have dependencies but having a separate package for some and not for others would be confusing

Yes, you convinced me. A package for each service-override

Do you thing that's an issue to have many packages?

As said above, I would l put all default extensions into one package.

I'm also aware that monaco-languageclient would probably depend on all service overrides, but that's maybe something that can be improved

Yes, eventually. Right now the conditional imports works well, IMO.

[CGNonofr]

I think each extension should be on a different package because almost nobody needs more than a few of them, and some of them are really heavy, especially the language feature ones

One package for all default-extensions with specific exports is fine, I think. If you look at the codingame npm overview it is kind of polluted now 😉 https://www.npmjs.com/search?q=%40codingame

The codingame npm overview is none of your concerns (:

Do you thing that's an issue to have many packages?

As said above, I would l put all default extensions into one package.

You don't really answer the question

Why do you think it's an issue?

Packages are really independent, have nothing in common, are sometime really heavy. I fail to see why you want to put them all in a single package.

I'm also aware that monaco-languageclient would probably depend on all service overrides, but that's maybe something that can be improved

Yes, eventually. Right now the conditional imports works well, IMO.

I can't really agree on that, it forces the bundles to create bundles for it, taking compilation time and making applications heavier for nothing

[kaisalmen]

Why do you think it's an issue?

It is largely deviating from what monaco-editor does itself and you create many new packages that you all need to maintain. If you are ok with, then why not, but I don't see a real net-benefit for the default extensions. Another idea: You could separate default-themes and default-languages. But if you are ok with maintaining all the packages, then go ahead. I won't block it. 👍

I can't really agree on that, it forces the bundles to create bundles for it, taking compilation time and making applications heavier for nothing

So, you would vote for removing importAllServices in monaco-languageclient? I found this rather helpful in the past, but I can't deny your argument here. The need for monaco-languageclient is actually dissolving. I will open an issue about that question over there.

One more thing: Shouldn't we combine this and #189 ? This change is much more than a 1.81.8. Binding the version of this lib hard to vscode comes in the way sometimes. Radical idea: next version is 2.0.1820 and then you can iterate to 2.0.1821 or 2.1.1820, WDYT?

[CGNonofr]

Why do you think it's an issue?

It is largely deviating from what monaco-editor does itself and you create many new packages that you all need to maintain.

Why do you think it's deviating from what monaco-editor does? monaco-editor doesn't have any optional feature. (except importing the editor api instead, but it's more a hack than a real feature)

edit: ok you are talking about the languages required to be installed one by one?

What about having a meta-package including all languages then?

If you are ok with, then why not, but I don't see a real net-benefit for the default extensions. Another idea: You could separate default-themes and default-languages. But if you are ok with maintaining all the packages, then go ahead. I won't block it. 👍

I'm not sure what you mean by "maintaining". There is no additional work.

I can't really agree on that, it forces the bundles to create bundles for it, taking compilation time and making applications heavier for nothing

So, you would vote for removing importAllServices in monaco-languageclient? I found this rather helpful in the past, but I can't deny your argument here. The need for monaco-languageclient is actually dissolving. I will open an issue about that question over there.

One more thing: Shouldn't we combine this and #189 ? This change is much more than a 1.81.8. Binding the version of this lib hard to vscode comes in the way sometimes. Radical idea: next version is 2.0.1820 and then you can iterate to 2.0.1821 or 2.1.1820, WDYT?

Indeed, that's probably a good idea to merge both changes in the same major version. I agree not being able to release a breaking version anytime is a problem... I hope there won't be the need for it when the lib will stabilized :D

You radical idea is interesting :) do you have any example of another project having the same issue? I didn't find any

[kaisalmen]

monaco-editor doesn't have any optional features

It contains all the basic-languages and themes in the main npm package. That's what I meant.

What about having a meta-package including all languages then?

Yes, good idea. Having both options seems like a good idea.

I'm not sure what you mean by "maintaining". There is no additional work.

You automated the work. That's good. The automation may/will break at some point. 😆

do you have any example of another project having the same issue? I didn't find any

I think that I have seen this somewhere, but I don't remember where.

[kaisalmen]

The need for monaco-languageclient is actually dissolving. I will open an issue about that question over there.

@CGNonofr I opened TypeFox/monaco-languageclient#543 regarding this.

[CGNonofr]

@kaisalmen

• feat: generate meta-package- pulling default extension sets

published as 1.81.8-next.3

[BusinessDuck]

Great work! A lot of packages from dist directory, when they are serving, didn't see any build tasks or something to serve dist directory.

[CGNonofr]

Great work! A lot of packages from dist directory, when they are serving, didn't see any build tasks or something to serve dist directory.

I'm sorry, I'm not sure to understand what you mean

[kaisalmen]

LGTM. The whole PR stack (this + #184 + #195) is working with monaco-languageclient.