search

microsoft / vscode-debugadapter-node

Debug adapter protocol and implementation for VS Code.
Other
271 stars 77 forks source link

Consider adopting more of a monorepo style #260

Closed connor4312 closed 2 years ago

connor4312 commented 2 years ago

I documented the release process in https://github.com/microsoft/debug-adapter-protocol/blob/gh-pages/contributing.md#releasing-dap-changes. Updating this package is a somewhat manual process since there are two different dependent packages that get published, and whoever is publishing needs to wait for the protocol publish to propagate before publishing the other package.

I suggest adopting a Lerna monorepo style for this. This is what I've done for the js-debug profilers (though the build is somewhat convoluted in there due to having multiple client/webview and extension host build targets...) which lets me just run lerna version patch to publish and update all packages. This will also enable us to automate publishing more easily 🙂

roblourens commented 2 years ago

How does lerna help you deal with having to wait for one package to be available in npm before you can update the dependency in another project?

connor4312 commented 2 years ago

The main reason for the wait is that the package-lock.json in the second packages needs to be updated with the new version. Well, doesn't have to be, but if it isn't then npm installing will create a dirty workspace, which is messy. Lerna will symlinks the packages locally, so that issue is resolved. npm doesn't actually enforce dependency versions on publish, so Lerna can just publish all relevant package versions simultaneously.

roblourens commented 2 years ago

Does that mean that package A that depends on B, contains package B when published?

connor4312 commented 2 years ago

No, it can still reference package B as its own separate npm package.

weinand commented 2 years ago

@connor4312 great idea to improve this (although I never had to "wait" for the protocol publish to propagate...)