Improvements after switching to npm workspaces

[kaisalmen]

Let's use this to exchange ideas and leave notes

• Anything odd with the examples and the description in the README?
• Should we produce bundled version (cjs/es/amd) that directly include the vscode-compatibility and all imported code and add them as separate exports to the package.json?
  • Best approach: If we could solve the whole vscode-compatibility problem just on a dependency level (e.g. monaco-vscode-api package), then users don't have to fiddle with bundlers
• Switch default and protected branch from master to main branch ✅

[CGNonofr]

There is no more webpack example, I think this is an issue since webpack is still the more widely used bundler

Should we produce bundled version (cjs/es/amd) that directly include the vscode-compatibility and all imported code and add them as separate exports to the package.json

I think it's a good idea, but it'll complexify the debugging (since the code will be transformed/bundled). Won't having 2 versions be confusing?

Another solution, with a bigger refactor, can be to create a new monaco-vscode-api package
Then we can have it as a dependency:

{
  "dependencies": {
    "vscode": "npm:monaco-vscode-api@<version>"
  }
}

[kaisalmen]

Another solution, with a bigger refactor, can be to create a new monaco-vscode-api package

On the long run this likely the better solution.

On branch https://github.com/TypeFox/monaco-languageclient/tree/libs-tsc I started some experiments. I fixed an issue that prevented the client lib to compiled to es6, but this is not sufficient to compile a working bundle (cjs or es)

There is no more webpack example, I think this is an issue since webpack is still the more widely use bundler

Yes, true, maybe we should add a second build/execution path for the client example

[kaisalmen]

If we could solve the whole vscode-compatibility problem just on a dependency level, then users don't have to fiddle with bundlers

[kaisalmen]

FYI, Just released 0.19.0-next.1

[kaisalmen]

@CGNonofr when is a good time to switch from master to main? How should we communicate this (just a sentence in the README)?

[CGNonofr]

Now seems to be a pretty good time, the main pain when switch the main branch are the currently open PRs, and there is none.

How should we communicate this (just a sentence in the README)?

I don't know, I'm not even sure it needs to be communicated specifically. A sentence in the README can't hurt

[kaisalmen]

Done! I switch the protection rule along. Shall I delete the master branch now?

[CGNonofr]

I do think so, along with all other temp branches (and add the rule that delete PR branches when merged?)

[kaisalmen]

(and add the rule that delete PR branches when merged?)

Adjusted configuration, let's see if it works as expected with next PR

[CGNonofr]

Can you please publish a version including the last changes?

[CGNonofr]

#342 in particular

[kaisalmen]

0.19.0-next.1 includes that already

[CGNonofr]

Oh you're right, sorry, I forgot about the path change

[kaisalmen]

I haven't done much here the last two to three weeks. I want to bring the webpack example back and merge your latest PR. Then we should release a new official version.

[kaisalmen]

@CGNonofr I have pushed the release preparation on main, but a I see error message coming up in the log when hitting code completion.
The node LS continues to work and there are no errors.

Do you have a quick idea?

[CGNonofr]

Since it just breaks the example and not the client, is it mandatory to fix it before the release?

[kaisalmen]

The problem resides from vite not properly reloading the commonjs package (client lib). This should work with the configuratrion applied, but it doesn't. The code is not ESM compatible and therefore cannot be loaded as module (we should change that on the long run IMO, but not now).
The workaround for now is if you want client lib code to be properly reloaded in the example:

• Run npm run watch from packages/client
• Restart npm run dev everytime you change code in the client lib
• Disable cache in browser or reload page with clearing cache

I will now release 1.0.0. Any objections?

[CGNonofr]

Not the slightest one :)

[kaisalmen]

And I repeat to myself never release on Friday 😆

[CGNonofr]

You're only releasing a library, people just have to not include and release their app today :)

[kaisalmen]

I closed the "get everything going again" issue and created a couple of enhancement issues that we can discuss.

[kaisalmen]

Should we clear-up the CODEOWNERS file? Should anyone apart from you and me be in there? WDYT?

[CGNonofr]

I don't think there is any point of having inactive users in this file as it's mainly used to set the PRs reviewers, isn't it?

[kaisalmen]

it's mainly used to set the PRs reviewers, isn't it?

Yes, exactly.

[kaisalmen]

@CGNonofr I think your ingenious ideas that lead @codingame/monaco-vscode-api pays off. 🎉 Awesome work!

[kaisalmen]

I think #363 can be closed as the issue can no longer be observed with 2.0.0+
We could add a Workaround section to the README to deal with #371 From my POI monaco-editor-core should no longer be used, but we should provide this know help to people
WDYT?

[CGNonofr]

You're right, I see no reason to use monaco-editor-core, but I don't see any reason to not provide the workaround

That being said, there is the same issue with every lib using monaco-editor

[kaisalmen]

but I don't see any reason to not provide the workaround

Now, you confused me. That means "yes, we add a workaround description", right? 🙂

[CGNonofr]

Yep!

[kaisalmen]

I used howfat to print the dependency tree npx howfat -r tree monaco-languageclient and it contains this weird dependency to vscode@1.1.37. Any idea why that is?

monaco-languageclient@2.0.2 (60 deps, 6.25mb, 839 files)
├── glob-to-regexp@0.4.1 (17.68kb, 5 files)
├─┬ vscode@1.1.37 (49 deps, 4.1mb, 470 files)
│ ├─┬ glob@7.2.3 (11 deps, 144.1kb, 56 files)
│ │ ├── fs.realpath@1.0.0 (13.12kb, 5 files)
│ │ ├─┬ inflight@1.0.6 (3 deps, 13.41kb, 16 files)
│ │ │ ├── once@1.4.0 (🔗, 1 dep, 6.84kb, 8 files)
│ │ │ ╰── wrappy@1.0.2 (2.89kb, 4 files)
│ │ ├── inherits@2.0.4 (3.87kb, 5 files)
│ │ ├── minimatch@3.1.2 (🔗, 3 deps, 56.41kb, 20 files)
│ │ ├─┬ once@1.4.0 (1 dep, 6.84kb, 8 files)
│ │ │ ╰── wrappy@1.0.2 (2.89kb, 4 files)
│ │ ╰── path-is-absolute@1.0.1 (3.53kb, 4 files)
│ ├─┬ http-proxy-agent@4.0.1 (6 deps, 150.5kb, 44 files)
│ │ ├── @tootallnate/once@1.1.2 (3.99kb, 4 files)
│ │ ├─┬ agent-base@6.0.2 (2 deps, 81.81kb, 21 files)
│ │ │ ╰── debug@4.3.4 (🔗, 1 dep, 48.04kb, 11 files)
│ │ ╰─┬ debug@4.3.4 (1 dep, 48.04kb, 11 files)
│ │   ╰── ms@2.1.2 (6.68kb, 4 files)
│ ├─┬ https-proxy-agent@5.0.1 (3 deps, 107.21kb, 32 files)
│ │ ├─┬ agent-base@6.0.2 (2 deps, 81.81kb, 21 files)
│ │ │ ╰── debug@4.3.4 (🔗, 1 dep, 48.04kb, 11 files)
│ │ ╰─┬ debug@4.3.4 (1 dep, 48.04kb, 11 files)
│ │   ╰── ms@2.1.2 (6.68kb, 4 files)
│ ├─┬ mocha@5.2.0 (25 deps, 1.86mb, 231 files)
│ │ ├── browser-stdout@1.3.1 (2.24kb, 4 files)
│ │ ├── commander@2.15.1 (58.38kb, 6 files)
│ │ ├─┬ debug@3.1.0 (1 dep, 58.5kb, 19 files)
│ │ │ ╰── ms@2.0.0 (6.12kb, 4 files)
│ │ ├── diff@3.5.0 (607.54kb, 27 files)
│ │ ├── escape-string-regexp@1.0.5 (2.63kb, 4 files)
│ │ ├─┬ glob@7.1.2 (11 deps, 144.5kb, 57 files)
│ │ │ ├── fs.realpath@1.0.0 (🔗, 13.12kb, 5 files)
│ │ │ ├── inflight@1.0.6 (🔗, 3 deps, 13.41kb, 16 files)
│ │ │ ├── inherits@2.0.4 (🔗, 3.87kb, 5 files)
│ │ │ ├── minimatch@3.1.2 (🔗, 3 deps, 56.41kb, 20 files)
│ │ │ ├── once@1.4.0 (🔗, 1 dep, 6.84kb, 8 files)
│ │ │ ╰── path-is-absolute@1.0.1 (🔗, 3.53kb, 4 files)
│ │ ├── growl@1.10.5 (57.88kb, 9 files)
│ │ ├── he@1.1.1 (105.48kb, 6 files)
│ │ ├─┬ minimatch@3.0.4 (3 deps, 54.66kb, 20 files)
│ │ │ ╰── brace-expansion@1.1.11 (🔗, 2 deps, 22.32kb, 16 files)
│ │ ├─┬ mkdirp@0.5.1 (1 dep, 41.49kb, 37 files)
│ │ │ ╰── minimist@0.0.8 (20.78kb, 14 files)
│ │ ╰─┬ supports-color@5.4.0 (1 dep, 9.59kb, 9 files)
│ │   ╰── has-flag@3.0.0 (3.05kb, 4 files)
│ ├── semver@5.7.1 (60.13kb, 7 files)
│ ├─┬ source-map-support@0.5.21 (2 deps, 874.46kb, 31 files)
│ │ ├── buffer-from@1.1.2 (4.93kb, 4 files)
│ │ ╰── source-map@0.6.1 (786.35kb, 20 files)
│ ╰─┬ vscode-test@0.4.3 (10 deps, 850.51kb, 137 files)
│   ├─┬ http-proxy-agent@2.1.0 (5 deps, 431.06kb, 68 files)
│   │ ├─┬ agent-base@4.3.0 (2 deps, 352.2kb, 41 files)
│   │ │ ╰─┬ es6-promisify@5.0.0 (1 dep, 315.62kb, 31 files)
│   │ │   ╰── es6-promise@4.2.8 (308.04kb, 27 files)
│   │ ╰── debug@3.1.0 (🔗, 1 dep, 58.5kb, 19 files)
│   ╰─┬ https-proxy-agent@2.2.4 (5 deps, 429.77kb, 67 files)
│     ├─┬ agent-base@4.3.0 (2 deps, 352.2kb, 41 files)
│     │ ╰─┬ es6-promisify@5.0.0 (1 dep, 315.62kb, 31 files)
│     │   ╰── es6-promise@4.2.8 (308.04kb, 27 files)
│     ╰── debug@3.1.0 (🔗, 1 dep, 58.5kb, 19 files)
├── vscode-jsonrpc@8.0.1 (191.82kb, 46 files)
├─┬ vscode-languageclient@8.0.1 (10 deps, 1.64mb, 320 files)
│ ├─┬ minimatch@3.1.2 (3 deps, 56.41kb, 20 files)
│ │ ╰─┬ brace-expansion@1.1.11 (2 deps, 22.32kb, 16 files)
│ │   ├── balanced-match@1.0.2 (6.78kb, 5 files)
│ │   ╰── concat-map@0.0.1 (4.75kb, 7 files)
│ ├─┬ semver@7.3.7 (2 deps, 115.05kb, 60 files)
│ │ ╰─┬ lru-cache@6.0.0 (1 dep, 29.68kb, 9 files)
│ │   ╰── yallist@4.0.0 (14.41kb, 5 files)
│ ╰─┬ vscode-languageserver-protocol@3.17.1 (2 deps, 885kb, 120 files)
│   ├── vscode-jsonrpc@8.0.1 (🔗, 191.82kb, 46 files)
│   ╰── vscode-languageserver-types@3.17.1 (361.57kb, 8 files)
├── vscode-languageserver-textdocument@1.0.5 (35.61kb, 8 files)
╰── vscode-uri@3.0.3 (170.78kb, 13 files)

[CGNonofr]

Are you sure howfat support dependency aliases? What is telling npm list ?

[kaisalmen]

Yes, you are right. Nevermind, it is a tool problem. I will use npm list from now on. npm list --all --depth 2 spits out the following 👍

└─┬ monaco-languageclient@2.0.2 -> .\packages\client
  ├── @types/glob-to-regexp@0.4.1
  ├── @types/node@16.11.7
  ├── @types/vscode@1.68.0
  ├── glob-to-regexp@0.4.1
  ├── vscode-jsonrpc@8.0.1
  ├─┬ vscode-languageclient@8.0.1
  │ ├─┬ minimatch@3.1.2
  │ │ └── brace-expansion@1.1.11
  │ ├─┬ semver@7.3.7
  │ │ └── lru-cache@6.0.0
  │ └─┬ vscode-languageserver-protocol@3.17.1
  │   ├── vscode-jsonrpc@8.0.1 deduped
  │   └── vscode-languageserver-types@3.17.1
  ├── vscode-languageserver-textdocument@1.0.5
  ├── vscode-uri@3.0.3
  └─┬ vscode@npm:@codingame/monaco-vscode-api@1.68.4
    └── monaco-editor@0.33.0

[kaisalmen]

@CGNonofr FYI I am on vacation the next two weeks and my activity will be very limited here and response times will likely be bad. C ya 👋

[CGNonofr]

No problem, enjoy your vacation! 🍹

[kaisalmen]

@CGNonofr I have closed multiple stale / outdated / issues or issues that were actually questions.

Will release 4.0.1 soon.

[kaisalmen]

@CGNonofr Good job

[CGNonofr]

Nice! how do you explain it?

[CGNonofr]

And what about the drop starting from mid-2021?

[kaisalmen]

The step rise, I don't really know. There is no smoking gun. Maybe, some of the packages using it got more popular or updated their CI pipeline 🙈 🙂 https://github.com/TypeFox/monaco-languageclient/network/dependents?dependent_type=PACKAGE

[kaisalmen]

And what about the drop starting from mid-2021?

Us not releasing new versions!? You created the codingame packge. 2022: us working together! 🎉