-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Extending computed class name identifiers throws: #2182
Comments
Can you elaborate a bit on what your use case is? i.e. why you don't want
to write 'a.foo' instead?
|
Webpack outputs code like this: class APIClientError extends __WEBPACK_IMPORTED_MODULE_3_helpers__["e" /* CustomError */] { And I am using CC to minify Webpack output. |
Duplicate of #2106 ? |
Not a duplicate - it's different. Fixing this would be a pretty simple change to the transpilation. Should be non-controversial as well. |
Just ran into this as well trying to replace the ever-bloating Babel with CC. Sadly I'm getting otherwise great results, but this error pretty much prevents us from adopting CC. |
@mohsen1 webpack would only replace that if you are extending a namespace / import / etc. that you have imported. Can you please share the original source? |
I don't exactly remember the original code anymore but this is close enough: // Errors.ts
export class CustomError {
// ....
} // SomeFile.ts
import { CustomError } from './Errors.ts';
class APIClientError extends CustomError {
// ...
} |
As workaround: // SomeFile.ts
import { CustomError } from './Errors.ts';
const CustomErrorTemp = CustomError;
class APIClientError extends CustomErrorTemp {
// ...
} |
The problem is from cases like this from typescript in ES6 mode: class APIClientError extends CustomError<API> {
// ...
} we cant do: const CustomErrorTemp = CustomError<API>; |
You should be able to do that with type CustomErrorTemp = CustomError<API>;
class APIClientError extends CustomErrorTemp {
// ...
} |
Hmm error:
|
oh right... sorry for misleading comment |
I ran into this issue and decided to take a stab at fixing it (despite never having touched the Closure Compiler codebase before...). As far as I can tell, the most elegant solution is to allow CC to consider terms like I don't want to submit a PR for this as my fix isn't perfect -- it fails some tests -- but perhaps somebody more familiar with the codebase can build upon it and complete it: https://github.com/Treeki/closure-compiler/tree/allow-constant-getelem-in-qualified-names |
Fixes #679. It's possible for a class declaration to extend an expression that does not have a symbol, for example when a mixin function is used to build a base class, as in `declare MyClass extends MyMixin(MyBaseClass)`. Handling this correctly is tricky. Closure throws on this `extends <expression>` syntax (see google/closure-compiler#2182). We would probably need to generate an intermediate class declaration and extend that. For now, just omit the `extends` annotation.
I deal with this limitation by manually extracting the base into a variable. I wonder if applying such a transform mechanically could be a correct resolution for this issue. I.e. for the code in the first comment, the rewriting could be:
Will this be typed as expected? |
Hmm, I see I unassigned MatrixFrog here, but I didn't intend to; I was just posting a comment. I don't think I even have a permission to assign or unassign anyone here. Please disregard and re-assign the issue back if you are an owner. |
I'm also experiencing this issue with webpack + closure compiler. Is there any ETA on a fix? |
See #2997 |
Closed by #2997 |
Input:
CC throws:
Is this by design? The JS code is valid.
The text was updated successfully, but these errors were encountered: