How to deal with incompatibility between @bufbuild/protobuf@"^2.0.0" and @bufbuild/protobuf@"^1.10.0

[jlewi]

I have a project stateful/vscode-runme that is currently importing the BSR registry stateful/runme.

I'm trying to add the newly created BSR registry jlewi/foyle to that project. When I run

npm install @buf/jlewi_foyle.bufbuild_es@latest

I can't a dependency conflict because they are depending on different versions of @bufbuild/protobuild.

npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR! 
npm ERR! While resolving: [email protected]
npm ERR! Found: @bufbuild/[email protected]
npm ERR! node_modules/@bufbuild/protobuf
npm ERR!   peer @bufbuild/protobuf@"^1.10.0" from @buf/bufbuild_protovalidate.bufbuild_es@1.10.0-20240212200630-3014d81c3a48.1
npm ERR!   node_modules/@buf/bufbuild_protovalidate.bufbuild_es
npm ERR!     @buf/bufbuild_protovalidate.bufbuild_es@"1.10.0-20240212200630-3014d81c3a48.1" from @buf/[email protected]
npm ERR!     node_modules/@buf/stateful_runme.bufbuild_es
npm ERR!       @buf/stateful_runme.bufbuild_es@"^1.10.0-20240701165231-bc6fb672a119.1" from the root project
npm ERR!   peer @bufbuild/protobuf@"^1.10.0" from @buf/[email protected]
npm ERR!   node_modules/@buf/stateful_runme.bufbuild_es
npm ERR!     @buf/stateful_runme.bufbuild_es@"^1.10.0-20240701165231-bc6fb672a119.1" from the root project
npm ERR!   2 more (@bufbuild/connect, @bufbuild/connect-node)
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! @buf/jlewi_foyle.bufbuild_es@"2.0.0-20240801044500-fba3b5ceb26b.1" from the root project
npm ERR! 
npm ERR! Conflicting peer dependency: @bufbuild/[email protected]
npm ERR! node_modules/@bufbuild/protobuf
npm ERR!   peer @bufbuild/protobuf@"^2.0.0" from @buf/[email protected]
npm ERR!   node_modules/@buf/jlewi_foyle.bufbuild_es
npm ERR!     @buf/jlewi_foyle.bufbuild_es@"2.0.0-20240801044500-fba3b5ceb26b.1" from the root project
npm ERR! 
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR! 
npm ERR! 
npm ERR! For a full report see:
npm ERR! /Users/jlewi/.npm/_logs/2024-08-01T14_56_16_986Z-eresolve-report.txt

npm ERR! A complete log of this run can be found in: /Users/jlewi/.npm/_logs/2024-08-01T14_56_16_986Z-debug-0.log

It looks like v2.0.0 was released a few days ago and per the documentation seems to introduce backwards incompatible changes to support protobuf editions.

Is there a way to control which version bufbuild/protobuf-es the generated SDK uses?

[V1210N]

I ran into this issue too. It seems to be because v2.0.0 went live recently, and it has some breaking changes.

The way I solved this was by just changing the SDK version back to 1.9.0.

Observation: This is in the repository's SDKs tab. Notice how it uses @v1.9.0-<stuff> instead of @latest.

I don't really like this change. They also removed classes for 2.0.0, which will require some big refactors by some people, breaking their CI/CD overnight. I hope 1.9.0 will last for a while. I feel like this is kind of a big deal and will honestly make me think twice before relying on Buf moving forward.

[jlewi]

That fixed it thank you very much.

[Evilu]

I ran into this issue too. It seems to be because v2.0.0 went live recently, and it has some breaking changes.

The way I solved this was by just changing the SDK version back to 1.9.0.

Observation: This is in the repository's SDKs tab. Notice how it uses @v1.9.0-<stuff> instead of @latest.

I don't really like this change. They also removed classes for 2.0.0, which will require some big refactors by some people, breaking their CI/CD overnight. I hope 1.9.0 will last for a while. I feel like this is kind of a big deal and will honestly make me think twice before relying on Buf moving forward.

For some reason, no matter what version i'm installing, it'll always compile the code with protoc-gen-es v2.0.0.
how did you managed to downgrade please?

[V1210N]

I ran into this issue too. It seems to be because v2.0.0 went live recently, and it has some breaking changes.
The way I solved this was by just changing the SDK version back to 1.9.0.

Observation: This is in the repository's SDKs tab. Notice how it uses @v1.9.0-<stuff> instead of @latest.
I don't really like this change. They also removed classes for 2.0.0, which will require some big refactors by some people, breaking their CI/CD overnight. I hope 1.9.0 will last for a while. I feel like this is kind of a big deal and will honestly make me think twice before relying on Buf moving forward.

For some reason, no matter what version i'm installing, it'll always compile the code with protoc-gen-es v2.0.0. how did you managed to downgrade please?

I just changed from:

npm config set @buf:registry https://buf.build/gen/npm/v1 
npm install --save "@buf/myprotopackage.connectrpc_es@latest" "@buf/myprotopackage.bufbuild_es@latest

To:

# I grabbed these from these versions from the SDK page
BUFBUILD_ES_VERSION="1.9.0-20240602183516-1d7340fa8862.2"
CONNECTRPC_ES_VERSION="1.4.0-20240602183516-1d7340fa8862.2"

npm config set @buf:registry https://buf.build/gen/npm/v1 
npm install --save "@buf/myprotopackage.connectrpc_es@${CONNECTRPC_ES_VERSION}" "@buf/myprotopackage.bufbuild_es@${BUFBUILD_ES_VERSION}

[timostamm]

Hey there, we're sorry for the inconvenience. The situation here is similar to any other case involving major version updates:

Imagine that you previously installed a package that depends on react 17. If you later install another package that depends on react 18, you'll get a peer dependency resolution error, because react 17 and 18 cannot be used at the same time. You'll have to install versions with matching peer dependencies, and install an older version of the second package that still uses react 17.

Generated SDKs remove quite a bit complexity, but this constraint still applies. Picking the plugin version in the BSR as described in #956 (comment) is the best solution.

@V1210N, can you elaborate how this broke CI/CD for you? All versions should be pinned in a lock file by the package manager when using generated SDKs, and builds should be reproducible.

Regarding the issue @Evilu ran into: As explained in #957 (comment), the latest version is used when generating with remote plugins if you don't specify the version. We realize this isn't ideal, and we're looking into improving the system, but it's unrelated to remote SDKs. The best solution is to specify the version.