babel-plugin-macros weekly downloads statistics

babel-plugin-macros 🎣

Allows you to build simple compile-time libraries

[![Build Status][build-badge]][build] [![Code Coverage][coverage-badge]][coverage] [![version][version-badge]][package] [![downloads][downloads-badge]][npmtrends] [![MIT License][license-badge]][license] [![All Contributors][all-contributors-badge]](#contributors-) [![PRs Welcome][prs-badge]][prs] [![Code of Conduct][coc-badge]][coc]

The problem

Check out this guest post on the Babel.js blog for a complete write up on the problem, motivation, and solution.

Currently, each babel plugin in the babel ecosystem requires that you configure it individually. This is fine for things like language features, but can be frustrating overhead for libraries that allow for compile-time code transformation as an optimization.

This solution

babel-plugin-macros defines a standard interface for libraries that want to use compile-time code transformation without requiring the user to add a babel plugin to their build system (other than babel-plugin-macros, which is ideally already in place).

Expand for more details on the motivation

For instance, many css-in-js libraries have a css tagged template string function:

The function compiles your css into (for example) an object with generated class names for each of the classes you defined in your css:

This class name can be generated at runtime (in the browser), but this has some disadvantages:

• There is cpu usage/time overhead; the client needs to run the code to generate these classes every time the page loads • There is code bundle size overhead; the client needs to receive a CSS parser in order to generate these class names, and shipping this makes the amount of js the client needs to parse larger.

To help solve those issues, many css-in-js libraries write their own babel plugin that generates the class names at compile-time instead of runtime:

If the css-in-js library supported babel-plugin-macros instead, then they wouldn't need their own babel plugin to compile these out; they could instead rely on babel-plugin-macros to do it for them. So if a user already had babel-plugin-macros installed and configured with babel, then they wouldn't need to change their babel configuration to get the compile-time benefits of the library. This would be most useful if the boilerplate they were using came with babel-plugin-macros out of the box, which is true for [create-react-app][cra].

Although css-in-js is the most common example, there are lots of other things you could use babel-plugin-macros for, like:

• Compiling GraphQL fragments into objects so that the client doesn't need a GraphQL parser • Eval-ing out code at compile time that will be baked into the runtime code, for instance to get a list of directories in the filesystem (see [preval][preval])

Table of Contents

• Installation • Usage • User docs • Author docs • Caveats • FAQ • How do I find available macros? • What's the difference between babel plugins and macros? • In what order are macros executed? • Does it work with function calls only? • How about implicit optimizations at compile time? • Inspiration • Other Solutions • Issues • 🐛 Bugs • 💡 Feature Requests • Contributors ✨ • LICENSE

Installation

This module is distributed via [npm][npm] which is bundled with [node][node] and should be installed as one of your project's devDependencies:

Usage

You may like to watch this YouTube video to get an idea of what macros is and how it can be used.

User docs

Are you trying to use babel-plugin-macros? Go to other/docs/user.md.

Author docs

Are you trying to make your own macros that works with babel-plugin-macros? Go to other/docs/author.md. (you should probably read the user docs too).

Caveats

Babel cache problem

Note: This issue is not present when used in Create React App.

Most of the time you'll probably be using this with the babel cache enabled in webpack to rebuild faster. If your macro function is not pure which gets different output with same code (e.g., IO side effects) it will cause recompile mechanism fail. Unfortunately you'll also experience this problem while developing your macro as well. If there's not a change to the source code that's being transpiled, then babel will use the cache rather than running your macro again.

For now, to force recompile the code you can simply add a cache busting comment in the file:

This problem is still being worked on and is not unique to babel-plugin-macros. For more details and workarounds, please check related issues below:

• babel-plugin-preval: How to force recompile? #19 • graphql.macro: Recompile problem (babel cache) #6 • twin.macro: Can't change taliwind config #37

FAQ

How do I find available macros?

You can write your own without publishing them to npm, but if you'd like to see existing macros you can add to your project, then take a look at the Awesome babel macros repository.

Please add any you don't see listed!

What's the difference between babel plugins and macros?

Let's use babel-plugin-console as an example.

If we used babel-plugin-console, it would look like this:

1. Add babel-plugin-console to .babelrc 2. Use it in a code:

When that code is run, the scope function does some pretty nifty things:

Browser:

Node:

Instead, let's use the macro it's shipped with like this:

1. Add babel-plugin-macros to .babelrc (only once for all macros) 2. Use it in a code:

The result is exactly the same, but this approach has a few advantages:

Advantages:…

Description from the npm listing.