refactor: adopt monorepo structure

[connor4312]

This adopts Lerna to assist with building a monorepo. I looked at pnpm and Yarn workspaces too--while these do some monorepo things, both are more primitive (and can actually be used by) Lerna, so I just stuck with that.

As referenced in the issue, with this change the protocol gets symlinked into the other packages locally. I removed the separate generator package so that the protocol produces all the things it needs without having an extra dependency. Then, when we want to publish, one can npm run version -- <version>, which will run lerna version to update the version of all packages and push their tags. Packages get published from the Github workflow.

Fixes #260

[connor4312]

it is not clear to me how to publish a pre-release version of the three modules. It would be nice if a lernaversion property with a "-pre.nn" suffix would automatically use the npm publish --tag next command. (I would like to publish 1.55.0-pre.0 version of the modules and then update Mock Debug to use the new modules and assess the "breakage" (if any ;-))

This works similarly to npm version, the format for this is lerna version pre(minor|major|patch), which bump the version with an alpha.0 tag by default. You can also set --preid if you wanted something other than alpha. So using the npm script you could do something like npm run version -- preminor --preid next, which currently would produce 1.55.0-next.0.

Btw, you can also safely experiment with lerna version locally since it will display the new version and ask for confirmation before bumping packages.

[weinand]

@connor4312 I've used npm run version -- preminor --preid pre and that creates and pushes the desired version to github.

But the npm packages cannot be published from the Github CI workflow because it prompts for input:

In addition I need the "next" tag for the published prerelease version to prevent that the default tag "latest" is used.

Should I publish to npm manually with lerna publish --dist-tag next or should this only be done through the git workflow?

[connor4312]

In addition I need the "next" tag for the published prerelease version to prevent that the default tag "latest" is used.

I think you want to run npm run version -- preminor --preid next. That will bump the version and push a git tag, which will trigger CI to publish the package.

But the npm packages cannot be published from the Github CI workflow because it prompts for input:

Fixing that in main, I will re-trigger the build to use the next tag.

[weinand]

In my understanding the "--preid" flag specifies the "prerelease identifier", not the npm tag. See https://github.com/lerna/lerna/tree/main/commands/version#--preid

Since I'm using the "prerelease identifier" pre, and the npm tag next since the DAP npm modules exist, I do not want to change this.

[connor4312]

Ah, I see. I modified the pipeline to handle that based off the tag contents https://github.com/microsoft/vscode-debugadapter-node/commit/7849cfd1f2a7436dbdc6d969bccda353ba4276f4

[weinand]

@connor4312 I tried to exercise the full "prerelease" work flow:

• in the DAP repo I made a cosmetic change to fix https://github.com/microsoft/debug-adapter-protocol/issues/233 on the "next" branch
• in the vscode-debugadapter-node repo (here) I've added a new script "sync-next-dap" to sync the "next" version of DAP.
• running the script correctly pulls the schema over

• but running npm run version -- preminor --preid pre doesn't do anything:

  

What am I missing?

It would be great if you could run the full "prerelease" work flow too.

[weinand]

@connor4312 today I learned that ESLint is not supported when using "lerna". Currently we are lucky because vscode-debugadapter-node does not use ESLint...

[weinand]

@connor4312 BTW, this shows the problem with the wrong tag:

Projects that just want to use the "latest" version of the DAP will get the "prerelease" version.

[connor4312]

Yes, that was a mistake when fixing the pipeline. I unpublished the other packages as a result of a failure but npm would not allow me to unpublish the debugprotocol project, as the debugadapter immediately depended on that version--even when the debugadapter was unpublished.

What am I missing?

You can use --force-publish for this, I added that to the npm script.

I learned that ESLint is not supported when using "lerna". Currently we are lucky because vscode-debugadapter-node does not use ESLint...

This should definitely work. If you'd like me to play around and set up eslint, let me know. Though it's to be seen whether the VS Code extension will work in that setup.

[weinand]

still the same:

[connor4312]

Sorry, pushed the correct fix

[weinand]

@connor4312 It works now, thanks! I've published the prerelease version 1.55.0-pre.1 as "next" and I've moved the "latest" tag back to the 1.54.0 version.

(and I've verified with Mock Debug that the modules still work...)

[weinand]

@connor4312 another nit:

the 3 DAP modules contain a tsconfig.json that results in errors:

[weinand]

@connor4312 I've fixed the issue with the published tsconfig.json

[connor4312]

Thanks! Didn't realize that tsconfig would get picked up.