ember-cli-babel icon indicating copy to clipboard operation
ember-cli-babel copied to clipboard

Depend on @babel/plugin-transform-typescript v7.16.0+

Open chriskrycho opened this issue 3 years ago • 3 comments
trafficstars

Babel v7.16.0 introduced support TypeScript 4.5's improvements to the import type syntax. Bump to require at least that version so ember-cli-babel users get support.

Previously, new users would get support by way of normal resolution for ^ dependencies, but existing codebases would end up broken if they pulled in a package which used the import type syntax and already had ember-cli-babel installed in a way which had resolved to an earlier version of the @babel/plugin-transform-typescript plugin.

Fixes #437.

chriskrycho avatar Feb 23 '22 20:02 chriskrycho

@chriskrycho you may need to restart the tests. looks like there was a timeout failure.

asakusuma avatar Feb 24 '22 16:02 asakusuma

Yeah, unfortunately I can't easily do so (don't have permissions). I might have to just re-commit and force push. 🙃

chriskrycho avatar Feb 24 '22 23:02 chriskrycho

Restarted build, but note this change isn't needed (it just makes things a tad easier for folks to update, since they can just bump their own direct ember-cli-babel version).

rwjblue avatar Mar 01 '22 19:03 rwjblue

Hello, just to report that I've experienced the same issue as @chriskrycho here and this note doesn't remedy the situation:

Restarted build, but note this change isn't needed (it just makes things a tad easier for folks to update, since they can just bump their own direct ember-cli-babel version).

Yarn as a dependency manager doesn't always pick the latest matching version of a subdependency, so while my application was directly relying upon latest ember-cli-babel, ember-cli-babel still relies on ^7.13.0 of ember-plugin-typescript and the resulting yarn.lock file chose 7.13.0, which is a technically valid match of the version specifier (because caret specifying earliest working major, not guaranteed latest).

We needed to use a yarn resolution to address this in the host app, which is not ideal.

mikesherov avatar Oct 18 '22 20:10 mikesherov

Right, the specific reason that behaves that way is that Yarn preserves existing versions of transitive dependencies wherever possible, to avoid having you get broken by adding or upgrading a separate package. That's generally preferable behavior, since users can resolve it in a variety of ways; but it can also be annoying here.

chriskrycho avatar Oct 18 '22 20:10 chriskrycho