Add exports=named to rollup output config

[BPScott]

Currently index.ts contains a single default export, and as output.exports is not specified it uses the value of "default". This causes problems with generating CommonJS output that is meant to be interchangeable with ESM output as detailed in https://rollupjs.org/configuration-options/#output-exports and https://www.typescriptlang.org/docs/handbook/modules/appendices/esm-cjs-interop.html. This also causes problems with typescript's moduleResolution:node16 option as the types types published by this package do match the commonjs output.

Prior to this change the types in index.d.ts are import { webpackStats } from './plugin'; export default webpackStats; which is correct for the esm build output.

The compiled index.cjs file however contains module.exports = webpackStats;. The correct types for this this content would be export = webpackStats.

---

To make the commonjs output match the types that are generated, and have commonjs and esm behave equivalently, this PR adds exports: "named" to the rollup output options.

This has no effect on the esm output, but changes the commonjs output in index.cjs file as follows:

- module.exports = webpackStats;
+ exports.default = webpackStats;

---

This is a breaking change, as it means commonjs consumers will have to change how they consume the package:

- const webpackStatsPlugin = require('rollup-plugin-webpack-stats');
+ const webpackStatsPlugin = require('rollup-plugin-webpack-stats').default

---

My general approach to working around this problem is "I only ever use named exports, I totally avoid export default", so personally I'd also change export default webpackStats to export {webpackStats} but I figure this is a less invasive change.

Summary by CodeRabbit

• Chores
  • Adjusted build output to consistently expose named exports in both ESM and CommonJS bundles, improving compatibility with bundlers and Node environments.
  • Reduces import ambiguity and prevents interop warnings/errors for consumers integrating the package.

[coderabbitai]

Walkthrough

Added the property exports: 'named' to the output configuration in both ESM and CommonJS build blocks within rollup.config.mjs. No other configuration keys or files were modified.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Tip

🔌 Remote MCP (Model Context Protocol) integration is now available!

Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats.

✨ Finishing Touches

• 📝 Generate Docstrings

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR/Issue comments)

Type @coderabbitai help to get the list of available commands.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Status, Documentation and Community

• Visit our Status Page to check the current availability of CodeRabbit.
• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

rollup.config.mjs (2)

17-17: Remove redundant exports option from the ESM build.

output.exports only affects non-ES formats (not esm). Keeping it here is harmless but misleading; Rollup will ignore it. Consider removing to avoid confusion. (rollupjs.org)

Apply this diff:

       format: 'esm',
-      exports: 'named',
       entryFileNames: '[name].mjs',

---

11-38: Follow-ups: package export map and subpath coverage.

Given you output both ESM (.mjs) and CJS (.cjs) for multiple entry points (index, transform), ensure package.json “exports” maps both conditions and subpaths, e.g.:

• "." → { import: "./dist/index.mjs", require: "./dist/index.cjs" }
• "./transform" → { import: "./dist/transform.mjs", require: "./dist/transform.cjs" }

This avoids resolution ambiguity in Node’s Node16/NodeNext moduleResolution and lets TypeScript pick the right flavor.

Would you like me to draft a package.json “exports” block and a short README note showing the new CommonJS usage?

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 0bfba07 and a45d91b.

📒 Files selected for processing (1)

• rollup.config.mjs (2 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

rollup.config.mjs (1)

src/plugin.ts (1)

• generateBundle (31-59)

🔇 Additional comments (1)

rollup.config.mjs (1)

30-30: Please manually verify the CJS output shape

The dist/ directory was not present in the verification environment, so we couldn’t confirm that your CommonJS build is emitting exports.default = … and no longer using module.exports = …. To ensure the intended breaking‐change behavior for CJS consumers, please:

• Run your build (e.g. npm run build) so that the dist/ directory and .cjs files exist.

• Confirm each dist/*.cjs contains at least one occurrence of

  exports.default =

  and no occurrences of

  module.exports =

• Optionally, add a CI check or post‐build script similar to the one below to automate this guard:

  #!/usr/bin/env bash
  set -euo pipefail
  
  echo "Verifying CommonJS output in dist/*.cjs…"
  rg -n "exports\\.default\\s*=" dist/*.cjs \
    || { echo "❌ Missing exports.default in CJS output"; exit 1; }
  ! rg -n "module\\.exports\\s*=" dist/*.cjs \
    || { echo "❌ Found legacy module.exports assignment"; exit 1; }
  
  echo "✅ CJS exports are correctly in named mode with default on .default"

Once confirmed, you may also want to update your docs/CHANGELOG.md to note that CJS consumers must switch from:

require('pkg')

to:

require('pkg').default

[vio]

@BPScott thank you for the pr!

Changing the export is a breaking change, and in the long run, we prefer to use default exports for ease of use. We are already working on fixing the support across all the export types(cjs, mjs, d.ts), will provide an update later this week.

How did you encounter the error? Did you update the plugin, or did you change the type of the vite/rollup config?

[BPScott]

I encountered this error when I changed the tsconfig that runs over my vite.config.ts (which imports rollup-plugin-webpack-stats).

I changed {"module": "esnext", "moduleResolution": "bundler"} to {"module": "nodenext", "moduleResolution": "node16"} to make typescript use the node module resolution strategies for my node based tools.

When I made this change I began to get the following type-check error on the line that did webpackPlugin()

This expression is not callable.
  Type 'typeof import("/Users/ben/projects/rollup-plugin-webpack-stats-typeerror/node_modules/rollup-plugin-webpack-stats/dist/index")' has no call signatures.

---

I've created a reproduction demo for you at https://github.com/BPScott/rollup-plugin-webpack-stats-typeerror

Clone the repo, and then run npm run type-check to run tsc and see the errors.