-
Notifications
You must be signed in to change notification settings - Fork 12.2k
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
Isolated declarations uses type information when emitting computed object keys #58533
Comments
FWIW, I don't think computed property names are compatible with When it comes down to it, there's no simple rule to transform from an expression computed name to a type one that actually works (without full potentially nonlocal context). Any "rule" we apply is heuristic, at best. :S Anyways, also ref #58490 which is on the same subject. |
@weswigham I agree with you - however I think ID already handles this on a checker level, because the checker disallows any types in computed key expressions that are not string literals, number literals, or This issue was not about changing the checker, just about changing the emit behaviour specifically for the allowed types (string literals, number literals, or There is no semantic issue here as far as I can tell, it's just something that is needed to achieve token level equality of the output. |
ish? The ID error can't be correctly emitted without full type information (see #58490), so you can't know if it's even safe to copy an expression computed name to a type computed name without doing whole-program typechecking. So while ID does have an error for this, it fails to emit it under the |
Yeah but that's already the case for other transforms, no? My understanding was that isolated declarations always operates on the assumption that the code is valid and does type check. Maybe I am misunderstanding this. |
I retract my previous comment. I don't think it is reasonable for the emitter to have to make the assumption that the ID checker passed. Doing so would make it impossible to analyze without TSC's ID checker whether an arbitrary given file is eligible for ID emit in the first place, which makes the performance gains quite useless. You would still have to check all files anyway to determine whether you can ID emit them before emit. |
These are all errors for now, but as we allow some of these forms as special cases, we do want to think about possibly aligning the emit output where possible, so this'll track that. |
π Search Terms
π Version & Regression Information
5.5.0-dev.20240514
β― Playground Link
https://www.typescriptlang.org/play/?isolatedDeclarations=true&ts=5.5.0-dev.20240514#code/KYDwDg9gTgLgBAYwgOwM7wNLAJ5wLxwBEMAFsFtoQNwBQNAJsAgDYCGUwcA5sxAEatmcAN4044uKEixEKdHADivAcwr4ipYEv6CKhMRKnR4SNPACqyAJYBHAK7AAytgC2fCMwBccO9fudUV3dmWglJcGNZMzgAORRLWwdnNw9vQJSQmgBfOiMZU3kAQXVRMIBtCgBdbxgoBwAaA3Ey5OCAOhgIR1qrZC4AFVYuargAM0FUYEbyhP9WjxHx5knpiTLtFSrvJZXsmiA
π» Code
π Actual behavior
TypeScript is emitting the computed property keys with type information that can not be determined without a type checker.
π Expected behavior
Additional information about the issue
No response
The text was updated successfully, but these errors were encountered: