LFX Mentorship: Migrating the CI/CD Pipeline from Babel to esbuild

What is LFX Mentorship?

The LFX Mentorship program is an initiative by the Linux Foundation designed to support contributors working on real-world open-source projects under structured mentorship. Unlike short-term contribution drives, LFX emphasizes sustained collaboration, architectural ownership, and disciplined engineering practices.

Rather than focusing solely on feature development, the mentorship encourages contributors to engage deeply with production-grade codebases, understand system-level trade-offs, and ship improvements that meaningfully impact maintainability and performance.

During my mentorship, I worked on modernizing the project’s CI/CD infrastructure by migrating the JavaScript build pipeline from Babel to esbuild — a change that significantly simplified the toolchain and improved build efficiency.

Project Introduction

Modern JavaScript projects often evolve organically. Tooling decisions made early in a project’s lifecycle can remain in place for years, even as the ecosystem advances. Over time, this can introduce unnecessary complexity, slower build times, and increased maintenance overhead.

The project’s (istio.io) CI/CD pipeline relied on Babel for transpilation and build processing. While Babel is powerful and highly configurable, its plugin-driven architecture and transformation-heavy workflow introduced additional layers of complexity into the build system. As the codebase grew, so did the configuration surface and the cognitive load required to maintain it.

Build performance is not merely a convenience — it directly affects contributor experience, review velocity, and deployment confidence. Slow pipelines discourage iteration. Complex configurations make debugging harder. Redundant transformation steps introduce avoidable technical debt.

The objective of this mentorship project was to modernize the build pipeline by replacing Babel with a more performant and simplified alternative. The migration aimed to:

• Reduce CI runtime
• Simplify configuration and dependency management
• Eliminate unnecessary transformation layers
• Improve long-term maintainability of the JavaScript toolchain

What initially appeared to be a tooling swap quickly became an architectural refactor of the project’s build philosophy.

What is Babel?

Babel is a widely used JavaScript compiler that transforms modern JavaScript (ES6+) into backward-compatible versions such as ES5. It enables developers to use newer language features while ensuring compatibility with older browsers and runtime environments.

At its core, Babel works by:

1. Parsing JavaScript source code into an Abstract Syntax Tree (AST)
2. Applying transformation plugins to modify the AST
3. Generating output code based on the configured targets

Its plugin-driven architecture makes it extremely flexible. Developers can enable presets such as @babel/preset-env to automatically transpile features based on browser targets, or add plugins to support experimental syntax, JSX, TypeScript, and more.

However, this flexibility comes with trade-offs.

Because Babel performs transformation-heavy compilation through multiple plugin passes, builds can become slower as the configuration grows. Each plugin introduces additional processing overhead. Over time, complex .babelrc configurations can accumulate, increasing maintenance complexity and making debugging more difficult.

In CI/CD environments — where builds run frequently and deterministically — even small inefficiencies compound. What began as a convenient compatibility tool can evolve into a performance bottleneck if not carefully managed.

While Babel remains powerful and relevant in many contexts, the project’s requirements had shifted toward speed, simplicity, and reduced configuration surface — prompting a reevaluation of the build pipeline.

What is esbuild?

esbuild is a modern JavaScript bundler and minifier designed for speed. Unlike traditional JavaScript tooling written in JavaScript itself, esbuild is written in Go and compiled to a native binary. This architectural choice enables it to achieve significantly faster build times compared to many existing toolchains.

esbuild performs bundling, transpilation, and minification in a highly optimized single-pass process. Rather than relying on extensive plugin chains and multiple transformation layers, it prioritizes simplicity and performance.

Key characteristics of esbuild include:

• Extremely fast compilation speed
• Minimal configuration surface
• Built-in support for modern JavaScript features
• Efficient bundling and tree-shaking
• Native executable performance (no Node-based transform overhead)

Instead of applying numerous transformation passes to an Abstract Syntax Tree (AST), esbuild focuses on efficient parsing and code generation with fewer intermediary steps. This reduction in transformation complexity directly translates into faster CI execution and reduced build latency.

While esbuild may not replicate every advanced transformation capability offered by Babel’s extensive plugin ecosystem, it excels in scenarios where performance, simplicity, and maintainability are primary concerns.

For this project, the trade-off was clear: prioritize streamlined builds and reduced complexity over heavy transformation flexibility.

Refactoring the Codebase for esbuild

One of the key insights during the migration was that tooling speed is not determined solely by the tool itself — it is also influenced by the shape and expectations of the codebase it processes.

While esbuild supports modern JavaScript features, it performs best when heavy transpilation steps are minimized. In the previous setup, Babel was responsible for transforming modern syntax into ES5-compatible output using multiple plugin passes. This introduced additional AST transformation overhead during every build.

To fully leverage esbuild’s performance-oriented design, parts of the codebase were refactored to reduce reliance on transformation-heavy features.

This included:

• Ensuring compatibility with ES5 where necessary
• Reducing the need for polyfills
• Avoiding syntax that required complex transpilation passes
• Simplifying module patterns where possible

By aligning the codebase more closely with the target runtime expectations, the build process required fewer transformation steps. Instead of layering compatibility through extensive plugin chains, the pipeline could operate with a more direct compilation path.

The result was a leaner build process:

• Fewer transformation passes
• Reduced plugin dependency surface
• Lower CI execution time
• More predictable output

This refactor reinforced an important architectural lesson: performance improvements are often achieved not just by replacing tools, but by reducing systemic complexity.

The migration was therefore not simply about adopting esbuild — it was about rethinking how much transformation the pipeline actually needed.

Technical Challenges During Migration

Although the migration significantly simplified the build pipeline, it was not without complications. Replacing a mature tool like Babel exposed subtle assumptions embedded in the existing workflow.

Source Map Inconsistencies

One of the first issues encountered was related to source map generation.

Babel’s transformation-heavy workflow produced source maps that aligned with its multi-stage compilation process. After switching to esbuild, discrepancies appeared in debugging environments. Stack traces and breakpoints did not always map correctly to the original source files.

This required:

• Revisiting source map configuration flags
• Ensuring consistent output formats
• Adjusting CI settings to preserve correct mappings
• Validating output behavior across local and CI environments

Debuggability is a non-negotiable aspect of production systems, so resolving source map inconsistencies was essential before the migration could be considered stable.

---

Circular Dependency Detection

Another challenge involved circular dependency behavior.

While the previous Babel-based setup tolerated certain module resolution patterns, esbuild surfaced circular dependencies more explicitly during bundling. In some cases, these cycles did not immediately break functionality, but they introduced warnings and potential execution-order risks.

This required:

• Identifying implicit circular imports
• Refactoring module boundaries
• Reorganizing dependency relationships
• Improving separation of concerns within the codebase

In retrospect, this was a beneficial side effect of the migration. The stricter bundling behavior encouraged better architectural hygiene and reduced hidden coupling between modules.

---

These challenges reinforced an important lesson: build migrations reveal structural assumptions. Tooling changes are rarely isolated; they often expose deeper architectural patterns that require attention.

Addressing these issues ensured that the migration was not only faster, but also cleaner and more maintainable.

Measurable Impact

The migration from Babel to esbuild resulted in a noticeable improvement in build performance and pipeline simplicity.

While exact benchmarks vary depending on environment and workload, CI build times were reduced significantly after removing transformation-heavy Babel passes. esbuild’s native execution model and streamlined compilation path eliminated much of the overhead previously introduced by plugin chains and layered transpilation.

Beyond raw speed improvements, the migration delivered structural benefits:

• Reduced dependency footprint
• Elimination of multiple Babel plugins and presets
• Simplified configuration surface
• Lower cognitive overhead for contributors
• More predictable build behavior in CI environments

The previous Babel-based setup relied on a relatively large dependency graph, some of which had become outdated over time. This increased maintenance burden and introduced unnecessary complexity into the pipeline.

By transitioning to esbuild, the project moved toward a leaner and more modern toolchain , one that prioritizes performance, clarity, and maintainability over excessive configurability.

In practical terms, contributors experienced faster feedback cycles, and the CI pipeline became easier to reason about and maintain.

Gratitude and Personal Reflection

LFX Mentorship Completion Certificate

This mentorship would not have been possible without the guidance and trust of my mentors, Craig Box and Daniel Hawton from Solo.io. Their feedback went beyond code reviews , they challenged assumptions, encouraged architectural thinking, and emphasized clarity over convenience.

What stood out most was their willingness to trust me with meaningful responsibility. Being treated not merely as a contributor, but as an engineer capable of making impactful decisions, was transformative.

Through this mentorship, I also had the opportunity to collaborate with engineers from organizations such as Google, Microsoft, Red Hat, and Solo.io. Working alongside professionals operating at that level exposed me to real-world engineering standards, thoughtful review culture, and disciplined system design.

During this period, I was fortunate to be ranked among the top contributors in the Istio repository alongside my mentors Daniel and Craig 😊. Sharing the leaderboard with my mentors was a quiet but powerful reminder that consistency and guidance truly accelerate growth.

Istio's Developer Contribution Stats

This experience meant more to me than just a technical achievement.

My interest in computer science began in 9th standard. At the time, I did not own a laptop. I borrowed one from my aunt when I was in 2nd year of my college , a 4GB RAM Intel i5 machine , and began learning to code on it. Resource constraints were constant, but curiosity was stronger.

Opportunities like this mentorship provided not just technical growth, but stability, direction, and validation.

To Craig, Daniel, and everyone who invested time in reviewing, guiding, and correcting me , thank you. This mentorship has had a lasting impact on both my engineering mindset and my confidence.

I remain deeply grateful for the trust placed in me, and I look forward to continuing contributing to open-source systems with the same discipline and responsibility I learned during this journey.