[VSCode] server-emitter use floating version for the peer-dependenies

[chunyu3]

E2E VSCode extension which will include client code generation and server code generation. E2E VSCode extension will install needed emitter packages if it is not installed before.

But now, we may meet with dependency version conflict issue.
e.g. First there is an old @typespec/[email protected] was installed, and it will dependent on @typespec/[email protected].
Then we will help to install @typespec/http-client-csharp package, and it will accept @typespec/compiler (>=0.63, <1.0.0), so when we install @typespec/http-client-csharp there will be peer-dependency conflict with @typespec/[email protected].

Option 1: workaround
To resolve the issue, the workaround is that we need to upgrade all existing emitter packages (client and server emitter) to latest version. This is a workaround, and it is not good customer experience: customer may not want to upgrade all the emitters when generate a code.

Option 2:
Use the floating version in peer-dependency.

As the client code emitter use peer-dependency with a floating version as following:

typespec/packages/http-client-csharp/package.json

Line 48 in c09f252

"peerDependencies": {

but the server emitter does not use floating version, see

typespec/packages/http-server-csharp/package.json

Line 53 in c09f252

"peerDependencies": {

Can server emitter has the same floating version as client emitter? In that case, we can resolve the peer dependency conflict when there are both client emitters and server emitters?

[allenjzhang]

Option 2 makes sense to me. @markcowl

[mikeharder]

Please include me in any conversations about package or dependency versions. I'd need to understand the broader context, but we should be able to configure things to allow mixing versions (or require matching versions) as we see fit.

Things may also look different pre-1.0 and post-1.0, depending how closely we decide to follow semver. Pre-1.0, NPM makes it more difficult to allow version ranges.

Our general approach so far, has been to allow broad ranges of versions at install time, so things will either just work (if no breaks) or fail at runtime. Post-1.0, we may want to offer stronger compat guarantees.

So right now, I agree http-server-csharp should match http-client-csharp. But I also want to think about our longer-term and bigger-picture versioning story.