Passes through spec to plugins.
I think this only affects arrow functions and template strings, but I haven't verified.
Support `spec` option
Add validateSpecOption test, remove redundant check
Fix linting issues
Add missing import
Fix linting issues in the test file
Github's editor has a habit of leaving trailing spaces 😅
Merge branch 'master' into env-spec
Seems like a good place to use Lodash's isUndefined and isBoolean since it's already in the package.json.
in this particular case it's part of the plugin so we would just need to move the dep to deps instead of devDeps
Ah, fair point. Is that something we want to avoid?
In the end it's a build tool so we should use when we would like to - hard for us just to implement everything when it's not needed but yeah something I've been struggling with sometimes. Sure we want to keep low dependencies and everyone complaining about Babel install times but hey we aren't getting any help and it just makes developing that much harder
But I want to mention other options too. If I'm not mistaken, asyncGenerators, generators and async options stay uncovered.
Moreover, by combining options, we may face cases when for some plugins we want to use certain option, but not for others.
For example, I want to run transform-es2015-arrow-functions with spec: true, but transform-es2015-template-literals without.
Diving deeper into the code, we may found that many plugins receive options they don't know and don't need (most).
Just topic to discuss rather after PR. During this stage, this PR is a good progress.
@yavorsky that was an issue with preset options when we originally talked about them - users wanted complete control and sebastian didn't want options at all. Logan suggested we allow options with predetermined options at first which is what we have atm
It's true a user might want true for 1 thing and false without but dono how much configurability we want
We should add a spec "integration" test in fixtures. I can do this and then merge