English for Rollup Bundler Developers

Rollup conversations center on one recurring question: “why is this dead code still in the bundle?” Answering it precisely requires vocabulary about side effects and module boundaries, not just “the bundler is being weird.”

---

Bundling Basics

Tree-shaking — the process of statically analyzing ES module imports/exports to eliminate code that is never actually used, keeping the final bundle smaller.

“That import is unused in this file, but tree-shaking can’t remove it because the module has side effects the bundler can’t prove are safe to skip.”

ESM output — producing a bundle in ECMAScript Module format (using import/export), as opposed to CommonJS or UMD, which is the format Rollup was originally built around and still handles best.

“We’re publishing this library with ESM output as the primary format — it’s what makes tree-shaking possible for anyone consuming it.”

Side effect — code that does something observable beyond just exporting values (like mutating a global or running on import), which prevents a bundler from safely removing it even if the export looks unused.

“Mark this file as side-effect-free in package.json only if you’re sure — if it secretly patches a global, tree-shaking it out will silently break consumers.”

---

Plugins and Config

Plugin — a piece of code that hooks into Rollup’s build pipeline to transform code, resolve non-JS imports, or add custom behavior (like handling CSS or TypeScript).

“Without the TypeScript plugin, Rollup has no idea what to do with a .ts file — it just sees an unknown extension.”

External dependency — a package explicitly excluded from the bundle and left as an import for the consumer’s own bundler or runtime to resolve, common for libraries that shouldn’t bundle their own dependencies.

“Mark react as external — we don’t want every consumer of this library shipping their own copy of React inside our bundle.”

Entry point — the file (or files) Rollup starts its dependency graph traversal from, determining what actually ends up reachable — and therefore includable — in the output.

“Nothing in that file will be tree-shaken correctly if it’s not reachable from an entry point — right now it’s dead code the bundler doesn’t even know exists.”

---

Output Shape

Code-splitting — breaking the bundle into multiple output chunks, often along dynamic import() boundaries, so consumers only load what a given code path actually needs.

“That dynamic import should create a separate chunk — if it’s still landing in the main bundle, check the code-splitting config.”

Chunk — one of potentially several output files Rollup produces, as opposed to a single monolithic bundle; shared dependencies between entry points are often extracted into their own chunk.

“There are three chunks here because two entry points share a common dependency Rollup pulled out on its own.”

---

Common Mistakes

• Blaming tree-shaking for a bundle-size problem without checking whether the offending module has side effects that legitimately prevent removal.
• Forgetting to mark peer dependencies as external, causing a library to ship duplicate copies of frameworks like React inside its own bundle.
• Assuming everything reachable from any file gets tree-shaken, when only code reachable from a declared entry point is even analyzed.

Practice Exercise

1. Explain, in two sentences, why marking a dependency as external matters for a published library.
2. Write a short PR comment diagnosing an oversized bundle as a missing external config rather than a tree-shaking bug.
3. Draft a message explaining why a file with global side effects can’t be safely tree-shaken even if its exports look unused.

Related Resources

• English for Vite Plugin Development
• English for Rspack Bundler Developers
• English for Rolldown Bundler Developers

Navigating Nuance: Dealing with Feedback & Collaboration

The core vocabulary of Rollup – terms like “tree-shaking,” “ESM,” “code-splitting,” and the various plugin configurations – is a solid foundation. However, successfully using this terminology effectively within a collaborative development environment requires more than just knowing the definitions; it’s about understanding the subtle nuances of communication that arise when discussing technical decisions with colleagues, particularly those whose first language isn’t English. A simple translation of “optimize bundle size” might not cut it. Instead, developers need to learn how to frame suggestions and respond to feedback in ways that are clear, constructive, and demonstrate a collaborative spirit.

Consider a scenario: you’ve spent the morning meticulously configuring Rollup with the terser plugin to aggressively minify your JavaScript code. Later, during a code review, your teammate, Alex, leaves a comment on your pull request: “This looks good, but are you sure about all this minification? It might negatively impact runtime performance in some environments.” Simply dismissing his concern with “I optimized it!” isn’t productive. A better response would be something like, “Thanks for flagging that, Alex. I’ve used terser to aggressively minify the code, but I understand the potential performance implications. Could you elaborate on which environments you’re concerned about? We could explore a more cautious configuration or potentially benchmark this change specifically in those environments to quantify any impact.” Notice the use of phrases like “flagging that,” “elaborate on,” and acknowledging the potential concern – these demonstrate respect for Alex’s perspective and open the door for further discussion. Similarly, when receiving criticism about your PR description, stating “I’ve made it as clear as possible” isn’t enough; a more helpful response would be “I appreciate the feedback on the PR description. Let me revise it to include specific details about the changes I’ve made and why they were necessary for code-splitting – perhaps adding something like ‘This change introduces code splitting to improve initial load times for smaller applications.’”

Furthermore, Slack conversations often require a degree of precision. A quick message like “Fixed bug in rollup config” isn’t sufficient; it lacks context and could lead to confusion. A more detailed message might be: “Resolved an issue where the resolveAlias plugin wasn’t correctly mapping certain modules during Rollup configuration. I’ve updated the plugin settings and tested thoroughly with a build. Let me know if you spot any regressions.” This demonstrates ownership, explains the problem, and invites further scrutiny.

# Example: Configuring Terser Plugin with Rollup
# This illustrates how to specify options for minification.
# Note: This is a simplified example; real-world configurations can be more complex.
const rollup = require('rollup')
const terser = require('terser')

const bundle = rollup.createBundle({
  format: 'esm',
  entryModules: ['src/index.js'],
  plugins: [
    {
      name: 'terser',
      setup(bundle) {
        bundle.write('dist/bundle.js', {
          format: 'es',
          terserOptions: {
            compress: {
              drop_console: true,
              ie8: false, // Disable IE8 support
            },
          },
        })
      }
    }
  ]
})

module.exports = bundle;

Ultimately, mastering the vocabulary of Rollup is only part of the equation. Being able to communicate effectively about it – acknowledging concerns, offering explanations, and collaborating with your team – will significantly contribute to a smoother and more productive development process. It’s about building bridges through clear and thoughtful communication, not just deploying optimized code.