Sollte ich Knotenmodule in mein Bibliothekspaket aufnehmen?

Question

Ich entwickle eine React-Komponentenbibliothek. Diese Bibliothek wird von mehreren internen NextJs-Projekten verwendet.

Aus Kompatibilitätsgründen mit NextJs muss diese Bibliothek irgendwann in CommonJs konvertiert werden.

Das Problem ist, dass einige NPM-Abhängigkeiten meiner Bibliothek CommonJS nicht verarbeiten. Dies ist beispielsweise bei Swiper der Fall.

Ich habe also zwei Möglichkeiten:

• Ich würde npm-Abhängigkeiten entweder als peerDependency deklarieren und sie dann von jedem Verbraucher meiner Bibliothek korrekt transpilieren lassen. Dadurch werden meine Bibliothekspakete leichter, es entstehen jedoch viele Konfigurationseinschränkungen in jedem Projekt (z. B. sowohl für NextJs als auch für Jest).
• Oder ich füge die npm-Abhängigkeit in mein Paket ein, was meiner Meinung nach ein Anti-Pattern ist, mir aber erlaubt, CJS und MJS offenzulegen: Die Konsumenten meiner Bibliothek haben fast nichts zu tun.

Ich kann mir auch eine Mischung aus beidem vorstellen: Ich ignoriere die Verwaltung aller Abhängigkeiten für CommonJs- und ES-Module und transponiere nur diejenigen, die notwendig sind.

Was denkst du?

Answer 1

我们也有同样的情况 - 我们有一个 Next.js 应用程序，它依赖于具有潜在 ESM 模块的核心库。不过，我建议不要捆绑您的依赖项。您的下游应用程序可能具有相同的依赖项，现在您最终将加载它们两次。而且您可能已经在其他第 3 方依赖项（具有 ESM 依赖项）中遇到了此问题。只需将它们添加到 next.config.js 中的 transpilePackages 列表中即可：https://nextjs.org/docs/app/api-reference/next-config-js/transpilePackages。我们还使用 next/jest ，它似乎也可以获取配置并且似乎可以工作。唯一需要注意的是，我发现我们必须转译 @babel/runtime 但只有在 jest 运行时才可以，否则它会破坏主应用程序。

/** @type {import('next').NextConfig} */
const nextConfig = {
  transpilePackages: ['@acme/ui', 'lodash-es'],
}
 
module.exports = nextConfig