Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit file-based plugins/presets to only exporting functions. #6494

Merged
merged 1 commit into from Oct 18, 2017

Conversation

Projects
None yet
3 participants
@loganfsmyth
Copy link
Member

loganfsmyth commented Oct 16, 2017

Q                       A
Fixed Issues? Fixes #1, Fixes #2
Patch: Bug Fix?
Major: Breaking Change?
Minor: New Feature?
Tests Added + Pass? Yes
Documentation PR
Any Dependency Changes?

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

module.exports = function(){
  return {
    presets: [{
      // Object allowed here, since it's not a string-based preset pointing at another file.
    }],
  };
};

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.

@babel-bot

This comment has been minimized.

Copy link
Collaborator

babel-bot commented Oct 16, 2017

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/5346/

@loganfsmyth loganfsmyth merged commit 1b43072 into babel:master Oct 18, 2017

4 checks passed

babel/repl REPL preview is available
Details
ci/circleci Your tests passed on CircleCI!
Details
codecov/project 87.29% (target 80%)
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@loganfsmyth loganfsmyth deleted the loganfsmyth:plugin-preset-limit branch Oct 18, 2017

@njugray njugray referenced this pull request Aug 20, 2018

Closed

webpack.config.js 出错 #86

@tomasdev tomasdev referenced this pull request Oct 2, 2018

Open

Support Babel 7 #9

@barlock barlock referenced this pull request Oct 4, 2018

Closed

Support babel 7 #5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.