Swiper v9+ ESM‑only Core vs swiper/react Wrapper: CJS Interop and React 18 StrictMode Double‑Init

Integration Boundary

Swiper v9+ ships as an ES‑module only distribution, removing the CommonJS/UMD entry points that v8 and earlier exposed. The swiper/react wrapper, which has existed since v8, is itself an ES module and therefore inherits the same constraint. This change forces toolchains that default to CommonJS – such as Jest’s default configuration or older webpack setups – to handle the module through transpilation or a transformIgnorePatterns exception.

React 18’s StrictMode double‑invokes effects during development. The Swiper React wrapper creates a Swiper instance on mount and destroys it on unmount. Under StrictMode, this cycle runs twice, potentially leaving duplicate slide elements, pagination bullets, or an already‑initialized instance behind. Swiper’s documentation does not guarantee StrictMode safety, and the typical workaround is to guard instance creation or disable StrictMode for the component.

Unresolved Decision

Which side of the integration boundary – the Swiper core or the React wrapper – should own the CommonJS interop layer for legacy toolchains? Additionally, how can the wrapper reliably avoid double‑initialization when rendered inside React.StrictMode without sacrificing the library’s out‑of‑the‑box functionality?

Specific Questions

• Should Swiper provide a dual ESM/CJS build to satisfy Jest and older bundlers, or should consumers be responsible for transpiling node_modules/swiper?
• What is the safest pattern for initializing a Swiper instance inside React.StrictMode to prevent duplicate slides or pagination?
• Does the module‑path change introduced in v9 (e.g., importing from swiper/modules) affect bundler resolution in a way that requires configuration changes beyond the default module field?