[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/http-server-csharp@0.58.0-alpha.3 was installed, and it will dependent on @typespec/compiler@0.60.0.
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/http-server-csharp@0.58.0-alpha.3.

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.

[chunyu3]

hello @allenjzhang @markcowl The same issue will occur in openapi emitter @typespec/openapi and @typespec/openapi3, @typespec/json-schema, @typespec/protobuf

[timotheeguerin]

Writing here what I said in the meeting, the http-server-csharp emitter is part of the workspace and follow the same release schedule as all other packages there. It just doesn't follow the same pinned version(0.64.x).
This means that it doesn't need to have those floating versiom in the same way the openapi3, protobuf and all our other emitters/libraries don't. You upgrade everything at once.

For the csharp-client emitter they release on a separate schedule which means they need to be compatible with at least 2 set of version to not have a period where we are stuck. We decided to have this very wide floating just for convinience