feat(zitadel-proto): add CJS and ESM support; export in Zitadel api s…

[tafaust]

…tructure; add build configuration

Definition of Ready

• I am happy with the code
• Short description of the feature/issue is added in the pr description
• PR is linked to the corresponding user story
• Acceptance criteria are met
• All open todos and follow ups are defined in a new ticket and justified
• Deviations from the acceptance criteria and design are agreed with the PO and documented.
• Vitest unit tests ensure that components produce expected outputs on different inputs.
• Cypress integration tests ensure that login app pages work as expected on good and bad user inputs, ZITADEL responses or IDP redirects. The ZITADEL API is mocked, IDP redirects are simulated.
• Playwright acceptances tests ensure that the happy paths of common user journeys work as expected. The ZITADEL API is not mocked but IDP redirects are simulated.
• No debug or dead code
• My code has no repetitions

[vercel]

@tafaust is attempting to deploy a commit to the zitadel Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
typescript-login	❌ Failed (Inspect)			Mar 18, 2025 7:12am

[peintnermax]

Do you see a way to not have to map every service like we do in /src/v2.ts?
This breaks the client package and login completely as they rely on the old scheme 🤔

[tafaust]

Ah, you're asking for an unstructured export on top of the structured export? Sure, I can add that!

[tafaust]

@peintnermax I added the required changes. Please be aware that apps/login/**/*.ts files sometimes do not respect ESM import syntax with .js (for example here:

typescript/apps/login/src/app/(login)/loginname/page.tsx

Line 11 in f310277

import { Organization } from "@zitadel/proto/zitadel/org/v2/org_pb";

) and we thus end up with both of these entries in package.json:

https://github.com/tafaust/zitadel-typescript/blob/fbef66800ea6a32e82050dc72c7859e2e59eb1f8/packages/zitadel-proto/package.json#L32-L41

Side note: Import from "@zitadel/proto/zitadel/org/v2/org_pb" will be possible in ESM and CommonJS likewise even though imho it is discouraged and should be seen as legacy (and to be deprecated). CommonJS should import directly from the api versions and ESM should specify the file extension. The "./zitadel/*" export promotes bad coding behaviour imho. Interested in your opinion about deprecation efforts.

[tafaust]

@peintnermax when writing a test for the legacy imports to work, I came across:

import { Organization as Org1 } from "@zitadel/proto/zitadel/org/v2/org_pb"; // does not work; has no exported member and defaults to the .d.ts file
import { Organization as Org2 } from "@zitadel/proto/zitadel/org/v2/org_pb.d.ts"; // works; exports the Organization type

Just to give you a taste what the omit of file ending (in a *.mjs file) will entail regarding my side note of the previous comment.

[tafaust]

@peintnermax please let me know if you want me to drop commit 347b418.