Skip to content
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

Fix createImportSpecifier with typescript 4.5+ #7426

Merged

Conversation

astegmaier
Copy link
Contributor

@astegmaier astegmaier commented Dec 10, 2021

↪️ Pull Request

This fixes #7325 and possibly also #7400. The issue, as @benpigchu pointed out here, was that Typescript 4.5 added support for type modifiers on specific import names. For example, it is now valid to write:

import { someFunc, type BaseType } from "./some-module.js";

Unfortunately, the way that the compiler API was changed to support this is not backward compatible :-(

Here's what the pre-4.5 API looked like:

createImportSpecifier(propertyName: Identifier | undefined, name: Identifier): ImportSpecifier;

And here's the new API (see PR):

createImportSpecifier(isTypeOnly: boolean, propertyName: Identifier | undefined, name: Identifier): ImportSpecifier;

Since there's no way that I know of to check a function's arity at runtime, I had to resort to a version check.

There were several other backward-incompatible changes in that PR (to updateImportSpecifier, createExportSpecifier and updateExportSpecifier), and I verified that we don't use these APIs in parcel.

💻 Examples

Without this change, when you have typescript 4.5+, @parcel/transformer-typescript-types will generate output like:

import { something as } from "./foo"

instead of

import { something } from "./foo

This change ensures that we do the right thing.

🚨 Test instructions

Several of the existing unit tests will break if you upgrade to typescript 4.5+ and don't apply this change, so it didn't seem necessary to add new ones.

I manually verified that with this change, and typescript 4.2.4 (the old version in the repo), all the unit tests still pass. You can test it yourself by modifying yarn.lock to revert back to 4.2.4, running yarn install, then yarn test:integration.

✔️ PR Todo

  • Filled out test instructions (In case there aren't any unit tests)
  • Included links to related issues/PRs

@height
Copy link

height bot commented Dec 10, 2021

Link Height tasks by mentioning a task ID in the pull request title or commit messages, or description and comments with the keyword link (e.g. "Link T-123").

💡Tip: You can also use "Close T-X" to automatically close a task when the pull request is merged.

.split('.')
.map(num => parseInt(num, 10));
// The signature of createImportSpecifier had a breaking change in Typescript 4.5.
// see: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-5.html#type-modifiers-on-import-names
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wowwwwww... TS doesn't follow semver?? Maybe we should pin our dependency on it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other side of that coin: #5978

@devongovett devongovett merged commit a9f310d into parcel-bundler:v2 Dec 13, 2021
@Jack-Works
Copy link

there's no way that I know of to check a function's arity at runtime

Yes you can

image

@mischnic
Copy link
Member

Though that would break if Typescript implemented createImportSpecifier using something like createImportSpecifier(...args) in the future.

bhovhannes pushed a commit to bhovhannes/parcel that referenced this pull request Dec 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[bug] Syntax error in TypeScript type defination files
4 participants