search

emberjs / ember-cli-babel

Ember CLI plugin for Babel
MIT License
153 stars 119 forks source link

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

Closed chriskrycho closed 1 year ago

chriskrycho commented 2 years ago

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.

asakusuma commented 2 years ago

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

chriskrycho commented 2 years ago

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

rwjblue commented 2 years ago

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).

mikesherov commented 1 year ago

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.

chriskrycho commented 1 year ago

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.