🐞 Bug: KoliBri Loader wird nicht als ESM module resolved

[mello-r]

Note

• [X] Ich achte beim Erstellen des Issues darauf, dass ich keine fachlichen und unternehmensinternen Details preisgebe.

---

Fehlermeldung

Error: Directory import '.../node_modules/@public-ui/components/dist/loader' is not supported resolving ES modules imported from .../@havdb/frontend-lib/dist/index.js
Did you mean to import @public-ui+components@2.0.3/node_modules/@public-ui/components/dist/loader/index.cjs.js?
Serialized Error: { code: 'ERR_UNSUPPORTED_DIR_IMPORT', url: '.../node_modules/@public-ui/components/dist/loader' }

Beschreibung des Fehlers

Der Loader von KoliBri wird nicht als ESM module resolved. Das Problem ist, dass das @public-ui/components package nicht als type: "module" definiert ist und so alle Dateien, die nicht speziell über export oder als .mjs Dateien definiert sind, als commonjs angesehen werden. Das fällt nicht immer auf, da beispielsweise Tools wie Vite die packages pre bundelen und so commonjs zu esm convertieren. Tools wie Vitest können das aber leider nicht. Da das komplette @public-ui/components package als commonjs definiert ist, hat vitest damit kein Problem, da es das komplette package als commonjs behandelt wird. Der Fehler taucht erst auf, wenn man über ein separates ESM package die @public-ui/components als peer dependency nutzt und so vom Konsumierenden erwartet wird, dass @public-ui/components auch ESM kann.

Mögliche Lösungen

• Den Loader über export in der root package.json definieren. Ab dann werden aber nur noch die exportieren Dateien zur Verfügung gestellt.
• Eine separate package.json in dem Loader Ordner und dort die Dateien korrekt exportieren. Der Vorteil dabei ist, dass weiterhin alle Dateien der KoliBri lib importieren werden können, auch ohne diese explizit im export zu definieren. Eine seperate package.json könnte man dann auch noch in den ESM Ordner legen.
• Das komplette @public-ui/components package als ESM definiert, aber dann existiert das Problem nur verkehrt herum. Meiner Meinung nach aber der richtige Weg, da das JavaScript Ecosystem zu langsam aber stetig zu ESM migriert.

Reproduktion

• https://stackblitz.com/edit/vitejs-vite-gb2zye?file=packages%2Fconsumer%2Ftests%2FsetupTests.ts

Schritte zum Reproduzieren des Verhaltens:

• Führe pnpm test aus
• Siehe Fehler

[mello-r]

Publint ist ein gutes Tool, um die Pakete generell zu überprüfen:

• https://publint.dev/@public-ui/components
• https://publint.dev/@public-ui/react
• https://publint.dev/@public-ui/themes
• https://publint.dev/@public-ui/schema

Man sieht, dass auch die anderen Packages ein paar Warnungen haben. Speziell beim @public-ui/themes Package gibt es noch das Problem, dass dort nur Javascript exportiert wird. Strikte Bundler erlauben dann keinen Import aus dem assets Ordner. Dieser müsste separat exportiert werden.

Publint kann auch lokal verwendet werden: npx publint.

[deleonio]

Hi @sdvg, kannst Du Dir das bitte mal unter dem Gesichtspunkt anschauen, was wir an unserem @public-ui/components verbessern könnten, damit ESM besser funktioniert.

Danke

[sdvg]

Hallo @mello-r (cc @deleonio @laske185)

Ich habe das Beispiel jetzt, auch ohne Anpassungen an KoliBri, lauffähig gemacht: https://stackblitz.com/edit/vitejs-vite-zeecmc

Änderungen waren im esm-package notwendig:

• Das Build-Script (tsup) hatte einen Typo im Dateinamen und hat nur CJS gebaut.
• Ich musste die Felder für module und exports definieren, letzteres inbesondere für Vitest.
• Vitest muss auf dem jsdom-Environment laufen, da KoliBri window direkt verwendet.

Den Module-Type von @public-ui/components würde ich aktuell noch nicht ohne Not ändern, nicht so lange es nicht der Standard von Stencil ist. Einen ESM-Build von KoliBri gibt es ja trotzdem, und dieser ist auch im module-Feld referenziert.

Um exports zu definieren sehe ich aktuell dann auch keinen Grund, das wäre wie oben beschrieben etwas umständlich, weil wir sehr viele Chunks haben, müsste also generiert werden.

Ist das ein Stand, mit dem ihr weiterarbeiten könnt?

[deleonio]

Hi @mello-r. @Chrisdo82,

Stefan hat eben berichtet, dass er es doch hinbekommen hat (m. Aussage im gestrigen JF).

Bitte schaut Euch das mal an und gebt und Feedback.

[mello-r]

@sdvg und @deleonio leider funktioniert das nicht. Pnpm Workspace Dependencies verhalten sich nicht wie Dependencies, die von npm installiert werden. Eine File-Dependency bildet das besser ab und mit dieser kommt auch wieder ein Fehler:

Error: Directory import '/home/projects/vitejs-vite-uibnkj/packages/consumer/node_modules/.pnpm/file+..+esm-package+esm-package-1.0.0.tgz/node_modules/@public-ui/components/dist/loader' is not supported resolving ES modules imported from /home/projects/vitejs-vite-uibnkj/packages/consumer/node_modules/.pnpm/file+..+esm-package+esm-package-1.0.0.tgz/node_modules/esm-package/dist/registerKoliBri.js
Did you mean to import @public-ui+components@2.1.3/node_modules/@public-ui/components/dist/loader/index.cjs.js?

Hier ist ein neuer Repro-Link: https://stackblitz.com/edit/vitejs-vite-uibnkj?file=package.json&view=editor. Stackblitz hat leider Probleme mit tgz-Dateien, manchmal funktioniert es, manchmal nicht. Also müsst ihr es eventuell runterladen.

Hattet ihr schon die Möglichkeit einen Blick auf die oben verlinkten publint errors zu werfen. Da wird zum Beispiel klar, dass viele Dateien einfach als CJS angesehen werden, da @public-ui/components keinen type in der package.json angegeben hat und somit als CJS Projekt angesehen wird. Hier der Fehler:

/dist/loader/index.js ist in ESM geschrieben, wird aber als CJS interpretiert. Verwenden Sie die Endung .mjs, z.B. /dist/loader/index.mjs.

Falls ihr die CJS public-ui Pakete vorerst auf CJS belassen möchtet, dann müsste dafür die Dateiendung .mjs für die ESM Dateien gesetzt werden.

Wie oben schonmal beschrieben, sollte man sich auch nochmal speziell @public-ui/theme anschauen, da dort export in der package.json verwendet wird, aber keine Assets exportiert werden. Somit kann man keine Assets in strikte Bundler importieren, obwohl dies eigentlich das Wichtigste im @public-ui/theme Paket ist.