Presets need new releases to fix TS 4.9 support

[aaronadamsCA]

💻

• Would you like to work on this feature?

What problem are you trying to solve?

After upgrading from Babel 7.18 to 7.20, I found that TypeScript 4.9 support was broken. I was still getting syntax errors on the satisfies operator.

After comparing #14211 to my installed dependencies, I found outdated transitive dependencies @babel/helper-skip-transparent-expression-wrappers@npm:7.18.9 and @babel/plugin-transform-typescript@npm:7.18.8 in my lockfile.

My Babel dependencies, all latest:

"@babel/core": "7.20.2",
"@babel/eslint-parser": "7.19.1",
"@babel/preset-env": "7.20.2",
"@babel/preset-react": "7.18.6",
"@babel/preset-typescript": "7.18.6",

Describe the solution you'd like

Releases of updated 7.20.x packages that cause these transitive dependencies to be upgraded.

Describe alternatives you've considered

I can manually resolve the transitive dependencies to newer versions, but this should not be necessary.

Documentation, Adoption, Migration Strategy

No response

[babel-bot]

Hey @aaronadamsCA! 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.

[JLHwung]

We cut a new release only when the package's source is changed. If a package's depending @babel/* is updated, there will not be a new release for that package. For example, @babel/plugin-transform-spread 7.19.0 requires @babel/helper-skip-transparent-expression-wrappers ^7.18.9, the semantic version range ^7.18.9 already covers @babel/helper-skip-transparent-expression-wrappers@npm:7.20.0, so we will not release @babel/plugin-transform-spread just to change ^7.18.9 to ^7.20.0.

This strategy minimizes the package that we need publishing and still ensures that users without a lockfile (fresh install) will get the latest packages. But package manager might prevent us from upgrading transient dependencies when a lock file presents. If you are using yarn, you can run yarn dedupe and remove redundant old @babel/* packages.

[aaronadamsCA]

Thank you for clarifying, appreciate it.

We use yarn dedupe, as does our Renovate config; the issue here is that there is no dependency path that requires newer versions of the underlying packages, so Yarn doesn't upgrade them. Babel 7.20 advertises TypeScript 4.9 support, but upgrading to Babel 7.20 doesn't actually deliver it without fiddling with the lockfile.

I'm sure there's a good reason to prioritize publishing fewer packages; I'm just surprised that you'd expect users to regenerate (or manually update) lockfiles to upgrade transitive dependencies. I would think, if a leaf package gets a new version, its ancestor packages would get corresponding new versions too.

[liuxingbaoyu]

I've thought about this, but I'm not sure it's any better if this would lead to frequent releases of many packages without any changes.

[nicolo-ribaudo]

The problem with publishing many packages is that whenever we publish more than ~15 packages the npm registry gives caching problems and npm install stops working for different users.

We could special-case some packages (preser-env, preset-typescript, core) to be released when their main dependencies have changes.

[liuxingbaoyu]

For anyone seeing this issue: We already support satisfies, it's just that if you're using *.lock you may need to manually update the plugin.
babeljs.io/blog/2022/10/27/7.20.0

[aaronadamsCA]

Modern versions of Yarn support yarn up -R "@babel/*" for exactly this sort of thing 🙌

[jordan-cutler]

How can I resolve this on yarn v1? What would I need to update in the yarn.lock file to do it safely?

[joshkel]

@lehighjcut , you should be able to edit your yarn.lock, remove any references to @babel/ packages that were installed as indirect dependencies, then rerun yarn.

See https://medium.com/@ayushya/upgrading-javascript-packages-deep-dependencies-using-yarn-8b5983d5fb6b for more details.

[jordan-cutler]

Thanks for that link @joshkel . I did try this just now and still no luck :/

First thing I tried was removing the reference to @babel/plugin-transform-typescript and then regenerating yarn.lock. It is showing it resolved as 7.20.7. Didn't work.

Next thing I tried was deleting all entries in yarn.lock that start with @babel then regenerating, also got 7.20.7 resolved for @babel/plugin-transform-typescript but still didn't work as well :/

EDIT: I think I found the culprit. Something is causing @babel/core to be regenerated at 7.12 rather than 7.20. Looking into it

It looks like Storybook mdx is pinning babel/core to 7.12. However, I do have 2 entries for @babel/core. One resolves to 7.20 and the other resolves to 7.12 (from storybook deps)

[jordan-cutler]

Nevermind, storybook doesn't seem to be affecting it as I attempted to remove all storybook dependencies and still not getting it to work.

I've also tried running yarn upgrade --scope @babel --latest and npx yarn-deduplicate yarn.lock --scopes @babel and still not working :/

[liuxingbaoyu]

https://classic.yarnpkg.com/lang/en/docs/selective-version-resolutions/
I don't recommend it, but you can try it.

[jordan-cutler]

Thanks @liuxingbaoyu , I appreciate you sending that over. It is one thing I haven't tried yet.

Is there a particular way you would recommend using it? One thing I don't totally understand is exactly which babel packages need to be what version for satisfies to be supported.

I see this in the changelog saying babel 7.20, but there are some packages that don't go up to 7.20 for example. So which ones is it saying need to be what version? If I knew that, maybe I could sort out what is going wrong.

https://github.com/babel/babel/blob/main/CHANGELOG.md

[liuxingbaoyu]

You can try to update @babel/plugin-transform-typescript, @babel/parser, @babel/types to the latest.

[liuxingbaoyu]

Is there a particular way you would recommend using it?

The way I recommend is to find which package pinned the babel version, but this can be difficult.

[bradenneufeld]

For any others trying to solve this issue with npm+webpack instead of yarn, I needed both these changes to get the satisfies operator working with Babel 7.20 and babel-loader 9+ for an existing project without deleting package-lock.json:

• Running npm update @babel/plugin-transform-typescript --save to update it from 7.18.10 to 7.20.7
  

• Find the entry for node_modules/@babel/preset-typescript in package-lock.json and its "dependencies" property. Manually update "@babel/plugin-transform-typescript": "^7.18.6" to "@babel/plugin-transform-typescript": "^7.20.7", save it, and run npm ci to do a clean install from package-lock.json
  

The first step won't update the @babel/preset-typescript dependencies, so the second step is still required to get this working without deleting package-lock.json (which you should never do). It seems releasing a new version of the package with updated dependencies would resolve this without having to perform manual surgery or deleting package-lock.json - this seems like a significant downside to the release strategy mentioned by @JLHwung.

[JLHwung]

@bradenneufeld Does npm dedupe work for you? We use Babel to build Babel, and run yarn dedupe whenever we upgrade @babel/* dependencies.

[7iomka]

Any news on this?