Dual-Engine Baseline Transpiler Assistant

My Project Story: Dual-Engine Baseline Transpiler Assistant The Dual-Engine Baseline Transpiler Assistant is a comprehensive tool I developed to automate cross-browser compatibility checks, ensuring JavaScript code adheres to the industry-standard Baseline status before it ever reaches production.

Inspiration: The Baseline Gap My inspiration came directly from a core pain point in professional web development: the trade-off between using modern JavaScript features (like Optional Chaining ?. or Nullish Coalescing ??) and ensuring broad user compatibility. Developers constantly face the fear that a new feature will work perfectly in Chrome but break silently in Safari or Firefox, often due to relying on outdated or inconsistent compatibility tables.

The introduction of the Baseline standard—a definitive framework for feature support across all major browsers—provided the necessary solution. My project was born from the need for a tool that could proactively enforce the Baseline standard directly within the continuous integration/continuous delivery (CI/CD) pipeline, shifting the burden of compatibility checking from the developer to the machine.

How I Built It: The Dual-Engine Core I chose a Node.js Monorepo structure to manage the complexity of integrating multiple transpilers and shared logic. The project's architecture relies on three core packages:

1. The Brain (@baseline/baseline-checker) This package serves as the single source of truth. It accesses the official, live web-features NPM package and exposes a simple function, getViolation(featureId), which returns a violation object if a feature is not Baseline compliant. This isolation ensures the checking logic is engine-agnostic and highly maintainable.

2. The Engines (@baseline/babel-plugin & @baseline/swc-plugin) I developed two separate plugins that use a Visitor pattern to traverse the Abstract Syntax Tree (AST) generated by their respective compilers.

They intercept code patterns (e.g., MemberExpression for method calls).

They call the central getViolation() function.

The successful implementation of both engines validates the project's Dual-Engine approach, offering maximum flexibility in modern build pipelines.

1. The Interface (@baseline/cli-tool) This package unifies the entire system, allowing the user to select their desired engine (Babel or SWC) and executing the correct pipeline based on the input, simplifying the end-user experience.

Key Learnings Building this project provided several critical technical and architectural insights:

AST Manipulation: I gained deep practical experience working with Abstract Syntax Trees, understanding how code is represented and how to write efficient Visitor functions to target specific syntax patterns (e.g., identifying Array.prototype.flat() by inspecting the specific MemberExpression node). I grasped how the AST represents the structure of code, which is essential for advanced tooling.

Monorepo Development: I mastered creating a highly coupled system where multiple packages (cli-tool depends on babel-plugin depends on checker) are linked locally using workspaces, ensuring cohesive dependency management and easy local development.

API Standardization: I learned to isolate the business logic (the checking algorithm) into a single, clean API (getViolation), making the consuming logic (the plugins) simple, maintainable, and engine-agnostic. This adheres to the principle of separation of concerns.

Challenges Faced The development process, particularly due to the low-level nature of transpiler integration, presented significant obstacles:

JSON & Configuration Sync: Initial attempts to run the system were repeatedly blocked by seemingly small errors like EJSONPARSE (extraneous commas) or incorrect file paths (MODULE_NOT_FOUND). This taught me the absolute necessity of rigorous file path resolution (path.resolve()) and strict JSON adherence in complex build tooling. The system is only as strong as its weakest configuration link.

The Persistent Babel Environment Crash: The most difficult challenge was debugging the internal Babel compiler crash (_Error is not a constructor) in the testing environment. This was eventually resolved by adding standard runtime plugins (@babel/plugin-transform-runtime) to fix dependency conflicts, but it required me to build a separate mock validator (validate-plugin-logic.js) to definitively prove that my custom plugin's logic was correct even while the official compiler environment was corrupted. This process proved the resilience and correctness of my code structure under duress.

SWC's Complexity: Integrating SWC required a different approach than Babel, often necessitating manual AST traversal (as opposed to a simple visitor object), which forced a deeper understanding of its high-performance architecture written in Rust.

The Dual-Engine Baseline Transpiler Assistant successfully delivers an automated solution for compatibility, proving that modern code can be reliable code. It demonstrates expertise in complex tooling integration, software architecture, and resilient pipeline development.

Built With

• babel-(@babel/core
• babel.config.js
• chalk
• commander.js
• github
• javascript
• monorepo
• node.js
• npm
• package
• swc