Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Use the peerDep to load types/template/traverse in plugins #6778
We've got it, so I'd say we should use it.
I haven't done it in this PR, but one big benefit here is that we can hoist more of our transform utilities into the top-level module scope to make the core of our plugin functions smaller, which should also help make them more readable.
The other reason I'm adding this is that I'd like to use a helper module for caching, and it'll require injecting code into each plugin. I could explicitly add a dependency to every plugin for that helper, but it's just as easy to expose that via babel-core and then not have to add dependencies to the plugins at all.
hzoo left a comment
sounds like a why not to me. Yeah I agree if we are going to go ahead with peerDeps since makes sense. Less deps in the plugins themselves and also guarantees it's the same version.
I wonder why a plugin needs
You're not wrong. I'm for leaving them for now for backward-compatibility for Babel 6, but we could definitely consider making
Is there still time to consider reverting this change?
For Meteor developers, this means anyone using custom
See meteor/meteor#9554 (comment) for an example. You might think that the peer dependency on
% npm --version 5.6.0 % npm install @babel/plugin-proposal-optional-chaining + @email@example.com added 2 packages in 1.078s
The only time I've seen a warning about the missing peer dependency is when I run
From what you've said above, you don't seem super convinced that this change was necessary (just that it was feasible and seemed safe), so I hope I've demonstrated a use case that will be impaired by this change. The wisdom of this change depends on the enforcement of peer dependency constraints, so it seems like a pretty serious problem that peer dependencies are not reliably enforced by
Yes, of course Meteor uses
Developers who want to use additional plugins can do so by installing them in their application's
Well this got long haha. I'm happy to discuss it further.
The primary reason for this approach, I'd say, is that separating control of
I didn't realize Meteor allowed users to customize via
Alternatively, it looks like https://github.com/meteor/babel/blob/master/package.json#L32 uses
The problem we're attempting to address here is that if a user has a
Compounding this, Babel 6 was around for a long time, and development of 7 has been slow because we took on too much. We'd really like to be releasing major versions much more often going forward. If every framework has a direct dependency on Babel, it's going to be extremely painful for users using more than one piece of tooling to upgrade because they'd have to upgrade all of their tooling to a new Babel version in sync to keep matching core versions.
It may be trivial in the single-case, but take for example a user using Meteor, with Jest to run tests, what happens when Meteor is using Babel 7 and Jest has updated to Babel 8? The user now has a
That has led us to aiming more for a peerDependency approach to allow packages using Babel to depend more broadly via say a peer dependency on
Given all that, the thought has been on a world where either:
Curious to hear your thoughts on alternative ways to address this. I'll happily admit that it's has downsides.
Meteor provides a consistent, well-tested core of Babel plugins and presets that are known to work well with each other, much like
We've been clear with our developers that
This abstraction has made it vastly easier to update Meteor from Babel 5 to 6 and now 7, because everything just works if you don't have a
Can you tell me if the following statement is accurate? If a Meteor power-user decides to use a custom Babel plugin via
If that statement sounds reasonable to you, then I suppose forcing users to install
We've been having a detailed discussion on the BabelJS #development slack channel: https://babeljs.slack.com/archives/C062RC35M/p1516393104000400
As illustrated by #9554, if a custom .babelrc plugin such as @babel/plugin-proposal-optional-chaining imports a missing dependency such as @babel/core, that failure causes inputFile.require to throw an exception that looks a lot like @babel/plugin-proposal-optional-chaining itself is missing, which can be confusing. This change does not fix the underlying problem (the @babel/core package still needs to be installed), but it does expose the exception so that the developer can do something about it, rather than merely leaving the ?. syntax uncompiled. Here's the offending line of code: https://github.com/babel/babel/blob/47ce7e71c9f97d151be493d05755562cb299fcca/packages/babel-plugin-proposal-optional-chaining/src/index.js#L2 Unfortunately, depending directly on @babel/core seems to be the policy for Babel plugins, per this PR: babel/babel#6778