Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Limit file-based plugins/presets to only exporting functions. #6494
Figured I'd see what people think about this. We've talked in the past about limiting plugins and presets to be functions, and I think decided there wasn't anything to gain, but as I've been thinking more about it, it has some implications for caching. If a file exports a plugin object directly, there's no way for us to expose an API to manage caching, so it encourages people to write plugins that don't take that into account.
I've been thinking about this more because I'm trying to piece together a system for creating a hash of Babel's input arguments so that we can skip compiling if we've compiled the code previously with the same settings. Ideally to do this, each item that is conceptually a standalone item should have a way to tell Babel what version it is, what name it has, and ideally anything that it might depend on. If file-based plugins and presets export an object, that's a no-go.
This PR allows
What this PR does is try to move us toward a world where essentially, a given plugin or preset will always have an "owner" that is clear. So file-based plugins and presets export functions, which means it is that function's responsibility to define some caching rules. That means that plugins and presets that are objects must be nested either inside a config file (thus caching is determined by the config file's caching logic), or inside the programmatic args for Babel, in which case I'm planning to introduce some logic for passing a cache invalidation value there somehow.