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
transform-runtime regression, not requiring _objectSpread
helper
#10261
Comments
Hey @fabiomcosta! We really appreciate you taking the time to report an issue. The collaborators on this project attempt to help as many people as possible, but we're a limited number of volunteers, so it's possible this won't be addressed swiftly. If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack community that typically always has someone willing to help. You can sign-up here for an invite. |
You could specify a helper version on {
plugins: [["transform-runtime", {
"version": "7.5.0"
}],
} When it is not specified, babel will assume you are using
@nicolo-ribaudo I don't think it is smooth for those who keep |
This seems to be the actual root cause behind our recent increase in bundle size. When we upgraded to 7.5.5, the helpers were updated too (through a new transform-runtime version). By keeping the configuration as it was, the Adding the version explicitly, as @JLHwung recommended above, does appear to fix the issue, with the file size going back down and the import being used again. If at all possible, I'd love if you could add autodetection as @JLHwung suggested, as in our case a simple upgrade produced a fairly complex issue to debug. |
With version 7.5.x of Babel, the object spread helper was updated to fix some issues. When we upgraded Babel to 7.5.5, it started trying to use the new helper to perform object spreads. This would have been fine, since the relevant package (transform-runtime) was part of the upgrade, but Babel sadly assumes that its version is older, instead of auto-detecting. This change explicitly indicates which version of the transform-runtime we're using, fixing the issue. It unfortunately adds extra maintenance overhead to Babel upgrades, but the Babel authors are considering adding the aforemention auto-detection, at which point we could remove the explicit definition. See babel/babel#10261
* Prevent duplicate Babel object spread helpers. With version 7.5.x of Babel, the object spread helper was updated to fix some issues. When we upgraded Babel to 7.5.5, it started trying to use the new helper to perform object spreads. This would have been fine, since the relevant package (transform-runtime) was part of the upgrade, but Babel sadly assumes that its version is older, instead of auto-detecting. This change explicitly indicates which version of the transform-runtime we're using, fixing the issue. It unfortunately adds extra maintenance overhead to Babel upgrades, but the Babel authors are considering adding the aforemention auto-detection, at which point we could remove the explicit definition. See babel/babel#10261 * Add note to changelog. * Add issue comment to Babel config too.
* Prevent duplicate Babel object spread helpers. With version 7.5.x of Babel, the object spread helper was updated to fix some issues. When we upgraded Babel to 7.5.5, it started trying to use the new helper to perform object spreads. This would have been fine, since the relevant package (transform-runtime) was part of the upgrade, but Babel sadly assumes that its version is older, instead of auto-detecting. This change explicitly indicates which version of the transform-runtime we're using, fixing the issue. It unfortunately adds extra maintenance overhead to Babel upgrades, but the Babel authors are considering adding the aforemention auto-detection, at which point we could remove the explicit definition. See babel/babel#10261 * Add note to changelog. * Add issue comment to Babel config too.
* Prevent duplicate Babel object spread helpers. With version 7.5.x of Babel, the object spread helper was updated to fix some issues. When we upgraded Babel to 7.5.5, it started trying to use the new helper to perform object spreads. This would have been fine, since the relevant package (transform-runtime) was part of the upgrade, but Babel sadly assumes that its version is older, instead of auto-detecting. This change explicitly indicates which version of the transform-runtime we're using, fixing the issue. It unfortunately adds extra maintenance overhead to Babel upgrades, but the Babel authors are considering adding the aforemention auto-detection, at which point we could remove the explicit definition. See babel/babel#10261 * Add note to changelog. * Add issue comment to Babel config too.
@JLHwung Thanks a lot for your suggestion, it fixed my issue too. Though I can't see it documented on https://babeljs.io/docs/en/babel-plugin-transform-runtime#options. Is this intended? As @sgomes said, I also found it hard to find the cause for why the inline helpers appeared. Is there somewhere where this is explained? And I don't really understand why the backwards compatibility is needed. I only have |
We are working on #10325 so that when
The helpers are inlined because
From what I have mentioned above, you can see that this mechanism ensures that |
I'm seeing the same issue @sgomes describes The Noticed this when updating from babel I updated versions to fix this issue #10179 Thanks for your awesome work on babel by the way. You folks rock |
Confirmed pinning version to DavidWells/analytics@3594c35#diff-26e31d5a6dff458a0b7db69a92db2308R15 Thanks @sgomes for the fix 😃 |
@JLHwung Thanks for you answers, that makes it clearer. |
Oh, that's not my fix at all! That was @JLHwung helpfully debugging the issue for @fabiomcosta 🙂 |
because of babel/babel#10261 if you don't speficiy a version of @babel/helpers to use, it will default to 7.0.0-beta.0 which doesn't have _objectSpread TEST PLAN: * Before checking this out, * run babel to transpile a file that uses object spread syntax, like `const foo = {...bar}` * you should see inline _objectSpread helpers like what is currently on npm. see for example: https://unpkg.com/browse/@instructure/ui-a11y@6.10.0/es/Dialog/index.js (See how that has a _objectSpread inlined in it?) * with this checked out, * run yarn build * Look at: packages/ui-a11y/es/Dialog/index.js * it should not have an inline _objectSpread function, but should Instead have a line like import _objectSpread2 from "@babel/runtime/helpers/esm/objectSpread2" Change-Id: I1a65ae85789848ad0702e43aafdc5580210942eb Reviewed-on: https://gerrit.instructure.com/208612 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Daniel Sasaki <dsasaki@instructure.com> QA-Review: Steve Jensen <sejensen@instructure.com> Product-Review: Steve Jensen <sejensen@instructure.com> Visual-Regression-Test: Steve Jensen <sejensen@instructure.com>
This also affects the new For anyone still wondering what the fix is, use
|
I've checked that specifying the "version" property solves the issue, when calling Babel directly to process each file. However, it doesn't affect a build generated with Webpack and Update 1: Specifically, this is happening for external modules, coming from Update 2: Solved. It's the same root issue, but it was already present in dependencies which were not being transpiled locally... |
This is now documented at https://babeljs.io/docs/en/babel-plugin-transform-runtime#version |
Bug Report
Current Behavior
The
objectSpread
is not being transformed by runtime-transform into a require to the respective helper. See REPL link.I've also setup a project to make it easy to show this issue, the instructions are on the
README
file, see https://github.com/fabiomcosta/babel_transform_runtime_helpers_bugOn that project you'll notice that
@babel/core
v7.0.0 used to behave properly, and the regression started happening on v7.0.1.Note that I'm mentioning
transform-runtime
because that's the plugin that actually activates this transform, but the issue seems to be inside@babel/core
(see the repro project).Input Code
REPL
If the issue hasn't been fixed yet, you'll see that
_objectSpread
didn't become a require from its respective helper:Expected behavior/code
The expected behavior for that is what used to happen on v7.0.0, the following code:
Should transpile to:
Environment
The text was updated successfully, but these errors were encountered: