Linking/local publishing Theia extensions

Hi, I want to develop my own Theia product using using my own extension that are currently not published to npm, but potentially will be in the future.

These extension reside in different repositories and I do not want to use relative path to them, since not every repository that has extension should be checked out every time I want to develop something.

Can you suggest something to locally publish or link uncommitted version of the extensions to be able to build locally? Using a local npm registry has the problem that I do not want to increment the version number every time I want to debug something locally. Yarn link on the other hand just seems to be broken. Or do you suggest to have a single repository for the theia extension such as you have for your theia extensions? I am trying not to do that, since the extensions should reside in the some repository as the code for their language server extension.

Any comment would be appreciated :slight_smile:

[original thread by Sören Domrös]

[Sören Domrös]

I currently have the following solution: I use verdaccio to locally publish my extension. Before publishing I unpublish already published extensions to be able to use the same version number. For the product (the browser version of theia) I clean the cache for my extensions, delete the node_modules and run yarn install --pure-lockfile and with my local registry as argument.

[Kavith Thiranga Lokuhewage]

I used yarn link to achieve same requirement. WDYM by yarn link seems broken?

[Kavith Thiranga Lokuhewage]

oh, yours haven’t still being published to npm, in my case, I have several older versions published already, so the initial extension build works fine. Then I use yarn link to link the local version of my other module

[Sören Domrös]

@kavith Yarn link needs something published to npm. For my case I can be that in a local npm registry. But doing that results in yarn link first copying the right dependencies in the node_modules and after that overriding the linked dependencies. I think this happens since they have the same version number. Preventing that results in a non working version. If I publish the same version locally it works somehow.

In my experience the best way is yarn workspaces.

then, yes the single repo, with all custom extension and your product app

you can then write scripts to publish custom extension independently to local repo or npmjs

I usually use yarn workspaces, too. When extensions/libs reside in different repos, I check them out within the root repo and add them to the workspaces.
You can achieve the same with git submodules, but they are hard to get rid of. My usecase is often that I have to adapt a library in order to get some new functionality into the product, so it’s important to be able to hook in/out packages on demand.

[Sören Domrös]

One repository with all extensions and yarn workspaces seems to be the way to go. I will adopt that.

[Peter Haumer]

We have a repo with only our extensions. We build that plus other things from different repos such as the LSP. For the Docker build we copy things in the right places and use file urls in package.json dependencies to avoid npm repos.