babel-plugin-macros VS babel-plugin-transform-react-remove-prop-types

One of the more promising alternatives is twin.macro - a Babel macro that processes Tailwind classes to generate JS objects understandable by various CSS-in-JS libraries. The developer experience (DX) of using it is amazing as you not only get all of Tailwind’s features without much change to your code, but you also get much more flexibility - all that on top of the traditional benefits of CSS-in-JS. Here’s an example code:

For example with Babel you could use babel-plugin-macros to execute this file at compile time and replace the file contents with the result of the computation. So appSettings would only have the configs for the current environment and nothing more and your source wouldn't need to change much.

It does require babel-plugin-macros which should also help with keeping things nice and performant in production. The package is part of a larger initiative im trying to achieve which is to create file-system based routing for all mainstream React and React Native routing packages. I have done everything I can to keep it as boilerplate free as I can. To give an example

MacroError: The macro you imported from "undefined" is being executed outside the context of compilation with babel-plugin-macros. This indicates that you don't have the babel plugin "babel-plugin-macros" configured correctly. Please see the documentation for how to configure babel-plugin-macros properly: https://github.com/kentcdodds/babel-plugin-macros/blob/master/other/docs/user.md

Yes, it also does that. https://github.com/kentcdodds/babel-plugin-macros

babel-plugin-macros

But sometimes Babel plugins may still come in handy. For example, there's a plugin to remove PropTypes you can use to make bundle size a bit smaller, and there's a [dedicated plugin for styled-components] that makes development and testing easier by, among others, adding component display names.

It's true that if you use something like babel-plugin-transform-react-remove-prop-types, then you will only need this runtime code in a dev build, not a production build. But a "dev dependency" is not really about whether it's a dev build or a prod build; it's about runtime vs build time. If you need it at runtime, it's a regular dependency.