Multi-version policy + Direct imports: Alternatives to single-version + barrel exports in micro frontend setup

[p-iknow]

Background

We're currently running a micro frontend architecture with multiple Next.js 14 applications using TypeScript, Tailwind CSS, and pnpm as our package manager on NX 19.42. Each micro frontend has significantly different requirements, and we want to avoid declaring all dependencies in the root package.json with a single version policy.

Purpose/Goal

We're seeking a solution that leverages pnpm workspaces effectively through NX while maintaining flexibility for individual applications. Additionally, we want to minimize NX's integration complexity and learning curve by using it at a minimal level initially, with the ability to adopt more features incrementally as needed.

Desired Outcome

We're looking for a setup where:

• Each micro frontend app can manage its own dependency versions independently using pnpm workspaces
• Teams can perform version bumps without being constrained by other applications
• We can avoid the high complexity and learning curve of NX's full integration suite
• We maintain a gradual adoption path for NX features
• We can leverage the latest TypeScript solutions effectively

Specific Questions

1. Multi-Version Policy & pnpm Workspaces

• Does NX support multi-version policies natively, or does it strictly enforce single version policy?
• How can we best utilize pnpm workspaces through NX to achieve independent versioning per application?
• Would upgrading to the latest NX version with modern TypeScript solutions help address these requirements?

2. CI/CD & Dependency Management

• How should we handle package install during CI builds for specific applications when each app has its own dependencies?
• What's the recommended approach for dependency resolution when building individual apps with independent versions?

3. Incremental NX Adoption

• Can we start with minimal NX usage and gradually adopt more integration features as our team's familiarity grows?
• What's the most lightweight way to use NX while still getting benefits from the build system?

Additional Critical Issue: Barrel File Exports

We're experiencing significant issues with barrel file exports that we consider a major problem:

Tree Shaking Limitations

• Tree shaking only works partially for client bundles
• Modules with side effects (CSS) are difficult to manage properly
• Managing sideEffects fields in package.json is challenging and error-prone

Direct Import Strategy

• We want to import directly from specific paths in our libraries instead of using barrel exports
• How can we configure NX/TypeScript to support direct path imports effectively?
• Are there best practices for structuring library exports to avoid barrel file issues while maintaining good DX?
• What's the recommended approach for handling CSS side effects in a multi-app monorepo setup?

---

Current Setup: NX 19.42, Next.js 14, TypeScript, Tailwind CSS, pnpm, Micro Frontend Architecture

Any insights on both the versioning strategy and barrel file alternatives would be greatly appreciated!

[Buttars]

Nx is lacking documentation on a multi-version policy implementation. Multiple independently versioned projects are explicitly supported per their documentation but I could not find any other documentation on how to implement this especially while using nx affected in CI.

My desired capability is to both be able to opt out of SVP for individual packages within a project or to opt out entirely if necessary.

Opting out of SVP is sometimes necessary for example, pushing a security hotfix that breaks one project but not others, or handling a peer dependency conflict for a dependency other projects do not rely on during an upgrade.