Add ESM wrapper to avoid dual package hazard

[timostamm]

This fixes the dual package hazard with the solution proposed in bufbuild/protobuf-es#509 (comment).

We've tested the approach in connectrpc/examples-es#1002 in various versions of Node.js, esbuild, parcel, rollup, vite, and webpack. Tree-shaking continues to work as expected with the "module" condition, and the dual package hazard is resolved with the esm wrappers in the "import" condition.

Note that we bump dependencies on @connectrpc/connect to ^1.1.2 and @bufbuild/protobuf to ^1.3.3 with this PR, meaning that the respective version or later needs to be installed. This is necessary because users are very likely to run into a dual package hazard otherwise.

[timostamm]

@paul-sachs, do you have an idea what the CI failure is about? I just ran pnpm run all at first, expecting it to run all things. But even when repeating the steps from ci.yaml, I don't see a diff 🤔

[paul-sachs]

@timostamm hmm I'll take a look. I've sometimes run into this if my branch is out of date (github compares using a merged branch).

[paul-sachs]

Ah, i see what's causing the issue. turbo is running test, and for some reason, it thinks it needs to run the generate step again (since it says cache has been missed). And the generate step doesn't run prettier as part of formatting. Why this isn't happening locally I don't know. I'll dig in some more and see if I can refine these dependencies.

[paul-sachs]

Alright, i figured it out. There is a timing aspect I suspect, but basically because the example app had a clean task that declared some outputs of dist/**, but in fact it's clean operation was just deleting the generated files (src/gen/**), this caused some confusion. Removing the clean task from the example app and just making it a part of generate fixes it.

[paul-sachs]

Technically, the problem could be seen that because we run the "Test" task as our last command in CI, it doesn't technically run format afterwards (and only keeps generated code the same due to cache hit). Perhaps moving format to run as the final task of ci would also make sense.

[timostamm]

Ah, good catch 👍

It's too early, but I think we can let the new script to generate esm wrappers do a bit more, so that we end up with just a single npm script for builds. One thing I have been experimenting with was a smarter clean before build, that doesn't actually delete files. That way, we don't need a clean script either, and I think this should fix the issue where the TypeScript language server fails to resolve types in the monorepo.

[paul-sachs]

@timostamm that sounds good. I keep eyeing vites lib mode, wondering if that provides a better experience over hand rolling these build processes every time but I haven't looked at how they handle the dual packages problem.