npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@remax/babel-plugin-macros

v2.7.1

Published

Allows you to build compile-time libraries

Downloads

7

Readme

Allows you to build simple compile-time libraries

Build Status Code Coverage version downloads MIT License

All Contributors PRs Welcome Donate Code of Conduct

Watch on GitHub Star on GitHub Tweet

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).

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

const styles = css`
  .red {
    color: red;
  }
`

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

console.log(styles) // { red: "1f-d34j8rn43y587t" }

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:

// Before running through babel:
const styles = css`
  .red {
    color: red;
  }
`
// After running through babel, with the library-specific plugin:
const styles = {red: '1f-d34j8rn43y587t'}

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.

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)

Table of Contents

Installation

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

npm install --save-dev babel-plugin-macros

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:

import macro from 'non-pure.macro';

-// Do some changes of your code or
+// add a cache busting comment to force recompile.
macro('parameters');

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:

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:
function add100(a) {
  const oneHundred = 100
  console.scope('Add 100 to another number')
  return add(a, oneHundred)
}

function add(a, b) {
  return a + b
}

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

Browser:

Browser console scoping add100

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:
import scope from 'babel-plugin-console/scope.macro'
function add100(a) {
  const oneHundred = 100
  scope('Add 100 to another number')
  return add(a, oneHundred)
}

function add(a, b) {
  return a + b
}

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

Advantages:

  • requires only one entry in .babelrc for all macros used in project. Add that once and you can use all the macros you want
  • toolkits (like create-react-app) may already support babel-plugin-macros, so no configuration is needed at all
  • it's explicit. With console.scope people may be fooled that it's just a normal console API when there's really a babel transpilation going on. When you import scope, it's obvious that it's macro and does something with the code at compile time. Some ESLint rules may also have issues with plugins that look for "global" variables
  • macros are safer and easier to write, because they receive exactly the AST node to process
  • If you misconfigure babel-plugin-console you wont find out until you run the code. If you misconfigure babel-plugin-macros you'll get a compile-time error.

Drawbacks:

  • Cannot (should not) be used for implicit transpilations (like syntax plugins)
  • Explicitness is more verbose. Which some people might consider a drawback...

In what order are macros executed?

This is another advantage of babel-plugin-macros over regular plugins. The user of the macro is in control of the ordering! The order of execution is the same order as imported. The order of execution is clear, explicit and in full control of the user:

import preval from 'preval.macro'
import idx from 'idx.macro'

// preval macro is evaluated first, then idx

This differs from the current situation with babel plugins where it's prohibitively difficult to control the order plugins run in a particular file.

Does it work with function calls only?

No! Any AST node type is supported.

It can be tagged template literal:

import eval from 'eval.macro'
const val = eval`7 * 6`

A function:

import eval from 'eval.macro'
const val = eval('7 * 6')

JSX Element:

import Eval from 'eval.macro'
const val = <Eval>7 * 6</Eval>

Really, anything...

See the testing snapshot for more examples.

How about implicit optimizations at compile time?

All examples above were explicit - a macro was imported and then evaluated with a specific AST node.

Completely different story are implicit babel plugins, like transform-react-constant-elements, which process whole AST tree.

Explicit is often a better pattern than implicit because it requires others to understand how things are globally configured. This is in this spirit are babel-plugin-macros designed. However, some things do need to be implicit, and those kinds of babel plugins can't be turned into macros.

Should macros be dependencies or devDependencies?

Macros are processed at build-time and not required at runtime. They should be devDependencies.

Inspiration

Thank you to @phpnode for donating the npm package babel-plugin-macros.

Other Solutions

Contributors

Thanks goes to these people (emoji key):

This project follows the all-contributors specification. Contributions of any kind welcome!

LICENSE

MIT