fix(sbg): generate unique class names for ts-extended classes #923
Conversation
|
run ci |
|
💔 |
|
Doesn't generate |
|
run ci |
|
💚 |
|
Note: The AST JavaScript parser only recognizes constructors with the following _super. call var _this = _super.call(this) || this;Super calls normally emitted by TSC will look something like return _super !== null && _super.apply(this, arguments) || this;This discrepancy in formats can cause the ASBG's This is not a problem for the time being, so long as the specific format in the constructor functions is not changed. |
| var variableRHS = firstLineOfCtorFunction.declarations[0].init; | ||
| var variableRHSPaths = variableRHS._paths.filter(node => types.isCallExpression(node)); | ||
| variableRHSPaths = variableRHSPaths.length > 0 ? variableRHSPaths[0] : null; | ||
| if (types.isMemberExpression(variableRHSPaths && variableRHSPaths.node.callee)) { |
There was a problem hiding this comment.
class X extends Y {
constructor(a: () => number) {
var x = a.call(null);
super(x + 2);
}
}Generates:
var X = /** @class */ (function (_super) {
__extends(X, _super);
function X(a) {
var _this = this;
var x = a.call(null);
_this = _super.call(this, x + 2) || this;
return _this;
}
return X;
}(Y));
I am not sure that the var x = a.call(null); won't be considered as the super call in the current implementation. Perhaps we should add some check for the "_this" identifier on the left hand side of the assignment and probably the "_super" identifier on the left hand side of the member access.
|
On the other hand, why don't we go one level up in the call stack and capture the location of the actual constructor function rather than the location of the super() call within? |
|
@PanayotCankov we could get the location of the constructor function statically while traversing the JavaScript AST. However at runtime, when |
|
💚 |
|
💚 |
Depends on: NativeScript/android#923 NativeScript/NativeScript#5257 BREAKING CHANGES `uglifyMangleExcludes` is no longer exported from the nativescript-dev-webpack plugin and shouldn't be used in the webpack configuration. Before: ``` // webpack.config.js // ... uglifyOptions: { mangle: { reserved: nsWebpack.uglifyMangleExcludes }, // ... } ``` After: ``` // webpack.config.js // ... uglifyOptions: { // ... } ```
Revert "fix(sbg): generate unique class names for ts-extended classes #923
Depends on: NativeScript/android#923 NativeScript/NativeScript#5257 BREAKING CHANGES `uglifyMangleExcludes` is no longer exported from the nativescript-dev-webpack plugin and shouldn't be used in the webpack configuration. Before: ``` // webpack.config.js // ... uglifyOptions: { mangle: { reserved: nsWebpack.uglifyMangleExcludes }, // ... } ``` After: ``` // webpack.config.js // ... uglifyOptions: { // ... } ```
Depends on: NativeScript/android#923 NativeScript/NativeScript#5257 BREAKING CHANGES: `uglifyMangleExcludes` is no longer exported from the nativescript-dev-webpack plugin and shouldn't be used in the webpack configuration. Before: ``` // webpack.config.js // ... uglifyOptions: { mangle: { reserved: nsWebpack.uglifyMangleExcludes }, // ... } ``` After: ``` // webpack.config.js // ... uglifyOptions: { // ... } ```
Depends on: NativeScript/android#923 NativeScript/NativeScript#5257 BREAKING CHANGES: `uglifyMangleExcludes` is no longer exported from the nativescript-dev-webpack plugin and shouldn't be used in the webpack configuration. Before: ``` // webpack.config.js // ... uglifyOptions: { mangle: { reserved: nsWebpack.uglifyMangleExcludes }, // ... } ``` After: ``` // webpack.config.js // ... uglifyOptions: { // ... } ```
|
I still have the problem extending custom classes with javaproxy |
5 participants
The changes in the PR aim to allow the runtime to create and process class names for Android classes extended in TypeScript code in a fashion similar to how Android classes are extended in JavaScript - the resulting class names contain the Extendee (base class), the file name, line and column of the constructor function definition, as well as the name of the new class (if anonymous).
This is necessary so that Java classes are more easily debugged, and also allows TypeScript-extended Android classes to function properly in an uglified webpack build.
Addresses #898, #692, and a couple other issues across the NativeScript organization.