Allow export default const enum, export default enum, export default … #18628

NaridaL · 2017-09-21T00:58:09Z

…declare class

Also export default namespace.

@mhegazy what about export default type foo = {} ?

NaridaL · 2017-09-21T01:12:59Z

Hmm it seems to pass here, but I'm getting...?

PS C:\Users\aval\tsdev\TypeScript> npx gulp runtests-parallel
C:\Users\aval\tsdev\TypeScript\node_modules\gulp\bin\gulp.js
[03:01:04] Requiring external module ts-node/register
[03:01:04] Using gulpfile ~\tsdev\TypeScript\gulpfile.ts
[03:01:04] Starting 'build-rules'...
snip snip
[03:01:05] Finished 'built\local\run.js' after 232 ms
[03:01:05] Starting 'tests'...
[03:01:05] Finished 'tests' after 2.34 μs
[03:01:05] Starting 'runtests-parallel'...
Running tests with config: {"light":false,"workerCount":4,"taskConfigsFolder":"C:\\Users\\aval\\AppData\\Local\\Temp/ts-tests34","noColor":false}
node built\local\run.js
Discovering tests...
Discovered 11206 test files in 665ms.
Starting to run tests using 4 threads...
Batching initial test lists...
Suboptimal packing detected: no tests remain to be stolen. Reduce packing fraction from 0.9 to fix.
Batched into 3 groups. Unprofiled tests including tsrunner-compiler://tests/cases/compiler/exportDefaultNamespace.ts will be run first.

  [........................................................................................................................................................................]
Test worker encounted unexpected error and was forced to close:
        Message: Cannot read property 'runner' of undefined
        Stack: TypeError: Cannot read property 'runner' of undefined
    at process.<anonymous> (C:\Users\aval\tsdev\TypeScript\src\harness\parallel\worker.ts:143:29)
    at emitTwo (events.js:125:13)
    at process.emit (events.js:213:7)
    at process.emit (C:\Users\aval\tsdev\TypeScript\node_modules\source-map-support\source-map-support.js:431:21)
    at emit (internal/child_process.js:774:12)
    at _combinedTickCallback (internal/process/next_tick.js:141:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)
[03:01:09] 'runtests-parallel' errored after 4.47 s
[03:01:09] Error: 2
    at formatError (C:\Users\aval\tsdev\TypeScript\node_modules\gulp\bin\gulp.js:169:10)
    at Gulp.<anonymous> (C:\Users\aval\tsdev\TypeScript\node_modules\gulp\bin\gulp.js:195:15)
    at emitOne (events.js:115:13)
    at Gulp.emit (events.js:210:7)
    at Gulp.Orchestrator._emitTaskDone (C:\Users\aval\tsdev\TypeScript\node_modules\orchestrator\index.js:264:8)
    at C:\Users\aval\tsdev\TypeScript\node_modules\orchestrator\index.js:275:23
    at finish (C:\Users\aval\tsdev\TypeScript\node_modules\orchestrator\lib\runTask.js:21:8)
    at cb (C:\Users\aval\tsdev\TypeScript\node_modules\orchestrator\lib\runTask.js:29:3)
    at failWithStatus (C:\Users\aval\tsdev\TypeScript\gulpfile.ts:680:9)
    at C:\Users\aval\tsdev\TypeScript\gulpfile.ts:697:17
    at <anonymous>

NaridaL · 2017-09-21T01:25:21Z

src/compiler/parser.ts

@@ -1310,7 +1310,11 @@ namespace ts {
            nextToken();


nextTokenCanFollowDefaultKeyword doesn't really seem like an accurate name considering it's looking at multiple? Same with nextTokenCanFollowModifier. Would something like declarationCanFollowExportDefault be more appropriate?

I think the name is fine since it doesn't take a declaration as input, it just goes to the next token and looks at its kind and maybe does some minimal lookahead.

k8w · 2017-09-25T12:06:22Z

export default const a = 'a';

Still get error in tsc 2.6.0-dev.20170921

mhegazy · 2017-11-08T17:58:51Z

@Andy-MS can you please review this change.. we need to make sure all LS features work as expected with this change..

ghost

Sorry for the delay

ghost · 2017-12-04T22:49:30Z

src/compiler/parser.ts

@@ -1310,7 +1310,11 @@ namespace ts {
            nextToken();
            return token() === SyntaxKind.ClassKeyword || token() === SyntaxKind.FunctionKeyword ||
                token() === SyntaxKind.InterfaceKeyword ||
+                token() === SyntaxKind.EnumKeyword ||


This is big enough now to deserve a switch statement.

ghost · 2017-12-04T22:51:03Z

src/compiler/parser.ts

                (token() === SyntaxKind.AbstractKeyword && lookAhead(nextTokenIsClassKeywordOnSameLine)) ||
+                (token() === SyntaxKind.DeclareKeyword && lookAhead(nextTokenIsClassKeywordOnSameLine)) ||


Also test export default declare namespace

Also we should probably allow the old module keyword here as equivalent with namespace for consistency.

What about export default declare abstract class ?

I think that should be supported too.

ghost · 2017-12-04T22:52:39Z

tests/baselines/reference/exportDefaultEnum.js

+var A;
+(function (A) {
+    A[A["FOO"] = 0] = "FOO";
+})(A = exports.A || (exports.A = {}));


This looks like an emitter bug -- It should be writing to exports.default.

ghost · 2017-12-04T22:53:38Z

tests/baselines/reference/exportDefaultNamespace.js

+        return 0xC0FFEE;
+    }
+    N.foo = foo;
+})(N = exports.N || (exports.N = {}));


Same emitter bug here -- should write to exports.default, not exports.N.

NaridaL · 2018-01-16T13:09:30Z

@k8w See https://esdiscuss.org/topic/why-is-export-default-var-a-1-invalid-syntax for why that doesn't make sense.

NaridaL · 2018-01-16T21:56:23Z

My turn to apologize for the delay; sorry.

I rewrote nextTokenCanFollowDefaultKeyword to use a switch statement.
Fixing the transformer is unfortunately not quite so simple.

Currently the enum transformer generates something like N = N || (N = {}), with the latter two N's then getting transformed into exports.N by the module transformer. Something like N = default || (default = {}) doesn't make much sense and doesn't get transformed correctly anyways. In any case this pattern isn't transferable for ES6 modules output.

In general, the behavior of ts.ts:visitEnumDeclaration (and visitModuleDeclaration) seems weird. Doing the || {} in the IIFE argument instead of in the initializer requires behavior conditional on the targeted module. (https://github.com/Microsoft/TypeScript/blob/master/src/compiler/transformers/ts.ts#L2613-L2619)

The latest commit transforms as follows for ES6, with the further changes for commonjs etc being handled by the respective transformers.

export default enum A { FOO = 2 };
// should be transformed into
var A = A || {};
export default A;
(function (A) {
    A[A["FOO"] = 2] = "FOO";
})(A);


export enum A { FOO = 2 };
// should be transformed into
export var A = A || {};
(function (A) {
    A[A["FOO"] = 2] = "FOO";
})(A);



namespace ts {
	export enum A { FOO = 2 };
}
// should be transformed into
var ts = ts || {};
(function (ts) {
	var A = ts.A || {};
	ts.A = A;
	(function (A) {
    	A[A["FOO"] = 2] = "FOO";
	})(A);
})(ts);

It's very much possible I've missed some slight semantic difference...
This changes touches > 800 tests so I've only committed tests=/exportDefault.*/

I'd appreciate feedback on my approach before I clean up the remaining errors/problems.

NaridaL · 2018-01-16T22:09:08Z

tests/baselines/reference/exportDefaultNamespace.js

+"use strict";
+exports.__esModule = true;
+// https://github.com/Microsoft/TypeScript/issues/3792
+var N = exports.N || {};


exports.N is a bit awkward here, but AFAIK should always be undefined, as things like the following aren't allowed?

export default class N {} export class N {}

As I mentioned above regarding enum, in this case N should only ever be a local binding inside the module. This should read:

var N = N || {}; exports["default"] = N; (function (N) { function foo() { return 0xC0FFEE; } N.foo = foo; })(N);

We also should consider allowing a "nameless" namespace:

// ts export default namespace { export function foo() { return 0xC0FFEE; } } // js var _a = {}; exports["default"] = _a; (function (_a) { function foo() { return 0xC0FFEE; } _a.foo = foo; })(_a); // alternatively exports["default"] = (function () { var _a = {}; function foo() { return 0xC0FFEE; } _a.foo = foo; return _a; })();

Thanks for the feedback, I'll get started on it. Would a nameless namespace be equivalent to a "namespace expression"? In any case I see some issues when module=es6:

export default namespace { export const a = 2; } // namespace merge export default namespace { export const b = 2; } // requires generated variable name: var _gen0 = {} export default _gen0; (function (_gen0) { _gen0.a = 2; })(_gen0); (function (_gen0) { _gen0.b = 2; })(_gen0);

As anonymous interfaces aren't allowed either currently, maybe this would be better handled as a separate issue?

That's a fair point, and perhaps we should hold off on nameless enum/namespace for now until the team has had an opportunity to discuss. My intuition is that you would not be able to merge with a nameless default namespace.

@DanielRosenwasser, @mhegazy: any thoughts?

rbuckton

Please address the above feedback and add tests for this emit output in the following contexts:

--target es5 --module commonjs
--target es5 --module amd
--target es5 --module system
--target es5 --module es2015
--target es2015 --module commonjs
--target es2015 --module amd
--target es2015 --module system
--target es2015 --module es2015

Also please add tests that verify declaration file (.d.ts) output.

rbuckton · 2018-01-17T20:22:42Z

src/compiler/parser.ts

+                    return lookAhead(nextTokenIsClassKeywordOnSameLine);
+                case SyntaxKind.DeclareKeyword:
+                    // "export default declare class" and "export default declare abstract class" are both valid
+                    return lookAhead(nextTokenIsClassKeywordOnSameLine) || lookAhead(nextTokenIsAbstractKeywordOnSameLine);


lookahead is not free, so I would recommend combining the two operations into a single lookahead. Also, you really want to do 2 token lookahead here for abstract:

default declare class - OK

default declare abstract - Not OK (especially if its followed by function, etc.)

default declare abstract class - OK

What about these:

default declare function

default declare async function (this syntax is invalid, however we report a more detailed error during grammar check)

default declare namespace

default declare module

default declare enum

default declare const enum

ClassDeclaration and FunctionDeclaration exported as default can elide the declaration name. Are we intending to support that for InterfaceDeclaration, EnumDeclaration, and ModuleDeclaration as well?

rbuckton · 2018-01-17T20:33:18Z

src/compiler/transformers/ts.ts

-                    && moduleKind !== ModuleKind.ESNext
-                    && moduleKind !== ModuleKind.System);
-        }
+        // function hasNamespaceQualifiedExportName(node: Node) {


Avoid commented code.

rbuckton · 2018-01-17T20:44:11Z

tests/baselines/reference/exportDefaultEnum.js

+"use strict";
+exports.__esModule = true;
+// https://github.com/Microsoft/TypeScript/issues/3792
+var A = exports.A || {};


If we intend for enum to work similar to class and function, then this is not the correct emit. Here you are exporting A as both A and default, where for a class or function it only exports default while the declaration name is a local binding only within the module.

With your new proposed emit this should instead be:

var A = A || {}; exports["default"] = A; (function (A) { A[A["FOO"] = 0] = "FOO"; })(A);

If we plan to allow elision of the enum name (like you can with ES6 classes and functions), then you might emit:

// ts export default enum { FOO = 1; } // js var _a = {}; exports["default"] = _a; (function (_a) { _a[_a["FOO"] = 0] = "FOO"; })(_a); // or, alternatively: exports["default"] = (function () { var _a = {}; _a[_a["FOO"] = 0] = "FOO"; return _a; })();

rbuckton · 2018-01-17T20:57:00Z

tests/baselines/reference/exportDefaultNamespace.js

+"use strict";
+exports.__esModule = true;
+// https://github.com/Microsoft/TypeScript/issues/3792
+var N = exports.N || {};


As I mentioned above regarding enum, in this case N should only ever be a local binding inside the module. This should read:

var N = N || {}; exports["default"] = N; (function (N) { function foo() { return 0xC0FFEE; } N.foo = foo; })(N);

We also should consider allowing a "nameless" namespace:

// ts export default namespace { export function foo() { return 0xC0FFEE; } } // js var _a = {}; exports["default"] = _a; (function (_a) { function foo() { return 0xC0FFEE; } _a.foo = foo; })(_a); // alternatively exports["default"] = (function () { var _a = {}; function foo() { return 0xC0FFEE; } _a.foo = foo; return _a; })();

mhegazy · 2018-01-18T00:46:21Z

I think we need to discuss the nameless declarations in the design meeting first.

NaridaL · 2018-01-20T21:52:00Z

I've overwritten the previous commits with two new ones. The first one includes all new tests and changes to parser.ts. The changed files are limited to the new tests and 2 others. The second commit changes the emit in ts.ts, which results in a lot of changed test results. I've closely reviewed the changes in my new tests and looked at a couple of the others at random.

There's still a weird exception for outputting comments when in system module in ts.ts. https://github.com/Microsoft/TypeScript/pull/18628/files#diff-c0d0e8b1528663b6cff3bb893150cec3R2873 This seems like it would better be properly handled in transformers/system.ts

I had to change my proposed transform slightly:

export enum A { FOO = 2 };
// should be transformed into
export var A = A || {};
(function (A) {
    A[A["FOO"] = 2] = "FOO";
})(A);
const usage = A.FOO

the above doesn't work, because binder.ts creates both an export and a local symbol for the enum, and the A in usage points to the local symbol. With module=es6 this ends as:

exports.A = {}
(function (A) {
    A[A["FOO"] = 2] = "FOO";
})(A);
const usage = A.FOO // breaks because no local is defined.

Forcing it to always use the exported version on emit breaks for export default, where it uses the non-existent "exports.A". As far as I can tell, changing this would require significant changes in the binder so that export enum A behaves likes export var A.

Current ES2015 output (which is correctly transformed by the following transformers):

const A = {};
export { A };
(function (A) {
    A[A["FOO"] = 2] = "FOO";
})(A);
const usage = A.FOO

On topic, why are some transformations delayed until onEmit? I couldn't find any hint in the source.

NaridaL · 2018-01-20T21:54:30Z

src/compiler/parser.ts

+                case SyntaxKind.DeclareKeyword:
+                case SyntaxKind.AsyncKeyword:
+                case SyntaxKind.TypeKeyword:
+                    return lookAhead(nextTokenIsIdentifierOrKeywordOnSameLine);


@rbuckton This simplified lookahead seems to be enough; see 5113249#diff-cc2127059a7624c4bd840e11d106cb81

NaridaL · 2018-01-20T21:56:04Z

src/compiler/parser.ts

                }
                return token() !== SyntaxKind.AsteriskToken && token() !== SyntaxKind.AsKeyword && token() !== SyntaxKind.OpenBraceToken && canFollowModifier();
            }
            if (token() === SyntaxKind.DefaultKeyword) {
-                return nextTokenCanFollowDefaultKeyword();
+                return nextTokenCanFollowDefaultModifier();


This whole parseModifiers method is very confusing...

NaridaL · 2018-01-20T21:58:11Z

src/compiler/binder.ts

                    node.localSymbol = local;
+                    local.exportSymbol = declareSymbol(container.symbol.exports, container.symbol, node, symbolFlags, symbolExcludes);


I flipped these two lines so I can access node.localSymbol in declareSymbol so can check if two default exports do not have the same identifier. Maybe this is better handled in checker.ts?

NaridaL · 2018-01-20T21:59:20Z

tests/cases/project/declarationsExportDefault.json

+        "namespace.ts",
+        "type.ts"
+    ]
+}


I added this project test to test the .d.ts output, is there a better way? Can I suppress the .js output?

We are trying to avoid adding new "projects" tests in favor test variations in compiler/conformance tests. You can set // @declaration: true in the compiler/conformance tests to get .d.ts output.

NaridaL · 2018-01-20T22:31:16Z

src/compiler/transformers/ts.ts

-                // declaration we do not emit a leading variable declaration. To preserve the
-                // begin/end semantics of the declararation and to properly handle exports
-                // we wrap the leading variable declaration in a `MergeDeclarationMarker`.
-                const mergeMarker = createMergeDeclarationMarker(statement);


MergeDeclarationMarker are unnecessary if the variable is initialized immediately. I think the logic handling those in the other locations is now dead.

Are there any other places that still create a MergeDeclarationMarker? If not are we able remove it completely from types.ts/factory.ts?

typescript-bot · 2018-06-13T00:58:58Z

Thanks for your contribution. This PR has not been updated in a while and cannot be automatically merged at the time being. For housekeeping purposes we are closing stale PRs. If you'd still like to continue working on this PR, please leave a message and one of the maintainers can reopen it.

alvis · 2018-06-14T01:03:27Z

ping @Andy-MS & @rbuckton

NaridaL · 2018-06-19T07:46:55Z

If someone OKs my proposed transform above I can rebase this (assuming there's still interest).

alvis · 2018-06-19T08:16:52Z

Yes. There're still people, like me, waiting for it being merged.

codetalks-new · 2018-07-19T02:15:00Z

If I export default a const enum, it will eventually produce undefined value.

const enum  Status{
   good = 0,
   bad = -1
}
export default Status; // this can lead undefined error. when using as `Status.good`

NaridaL · 2018-07-19T05:15:49Z

@banxi1988 I don't follow...?

codetalks-new · 2018-07-20T15:12:23Z

@NaridaL sorry, I do actually encountered the undefined error caused by export default const enum type in my project. but Haven't reproduce it in a demo project. I'll try to reproduce it with a webpack configured project.

RyanCavanaugh · 2018-09-05T15:40:02Z

@NaridaL if you can get this merged up with master we can give it a fresh review. Thanks for your patience!

…icrosoft#3792 (comment). Added corresponding tests. NB: export defaults are not yet transformed correctly.

NaridaL · 2018-09-23T21:13:20Z

Rebased it...

In: tests/baselines/reference/transformApi/transformsCorrectly.transformAddCommentToNamespace.js

The comment is being output both on the var declaration and the module statement.

Could someone please clarify what the difference between an emit node and a synthesized node and when/why they should be used? Setting a flag or comment range is clearly the cause of the above issue, but it's not obvious where... it works fine in the tests I added.

rbuckton · 2019-02-06T01:51:00Z

EmitNode is not an actual AST node, but rather is an extra set of properties attached to a Node that effects emit. These properties aren't added to a Node directly as it would increase the memory requirements for Node in the language service, which rarely needs to perform emit.

A "synthesized" node is a Node that was created synthetically as part of a transformation rather than created by the parser "from source". A "synthesized" node has NodeFlags.Synthesized in its flags property, and usually has a pos and end of -1 (although these can be set to actual positions if the synthesized node corresponds to an actual node.

rbuckton · 2019-02-06T01:52:19Z

If you set pos or end on a synthesized Node (i.e. via the setTextRange function), it will use those positions for comment emit. You can disable this by setting an EmitFlag of NoComments via the setEmitFlag function.

rbuckton

There are a number of errors in the various module-specific emit tests that need to be addressed.

rbuckton · 2019-02-06T19:32:10Z

src/compiler/transformers/ts.ts

            setTextRange(enumStatement, node);
+            setCommentRange(enumStatement, node);


It shouldn't be necessary to set the comment range if you've also set the text range. Setting the text range sets the pos and end of enumStatement to be that of node, which affects both comment emit and source map emit. Setting the comment range should be redundant.

rbuckton · 2019-02-06T19:34:11Z

src/compiler/transformers/ts.ts

            addEmitFlags(enumStatement, emitFlags);
            statements.push(enumStatement);

            // Add a DeclarationMarker for the enum to preserve trailing comments and mark
            // the end of the declaration.
-            statements.push(createEndOfDeclarationMarker(node));
+            // statements.push(createEndOfDeclarationMarker(node));


Do we no longer need the end-of-declaration marker node? It's used to handled deferred exports for ES2015, CommonJS, AMD, and SystemJS. If we no longer need it I would remove this line rather than just comment it.

rbuckton · 2019-02-06T19:35:48Z

src/compiler/transformers/ts.ts


            //  (function (x) {
            //      x[x["y"] = 0] = "y";
            //      ...
-            //  })(x || (x = {}));
+            //  })(x);


Is it possible to make this change to emit behavior conditional on when it is necessary rather than always emit this way? It would significantly reduce the number of test changes in the PR.

rbuckton · 2019-02-06T19:39:03Z

src/compiler/transformers/ts.ts

-                // declaration we do not emit a leading variable declaration. To preserve the
-                // begin/end semantics of the declararation and to properly handle exports
-                // we wrap the leading variable declaration in a `MergeDeclarationMarker`.
-                const mergeMarker = createMergeDeclarationMarker(statement);


Are there any other places that still create a MergeDeclarationMarker? If not are we able remove it completely from types.ts/factory.ts?

rbuckton · 2019-02-06T19:41:03Z

src/compiler/parser.ts

@@ -4101,7 +4126,7 @@ namespace ts {

                    sourceFile.flags |= NodeFlags.PossiblyContainsImportMeta;
                }
-                else {
+            else {


The indentation here is wrong.

rbuckton · 2019-02-06T20:14:45Z

tests/baselines/reference/exportDefaultNamespace.js

+/**
+ * namespace B 1 leading comment
+ */
+var B = {};


B is never exported, despite the fact it is declared as export enum B in the test.

rbuckton · 2019-02-06T20:18:39Z

tests/cases/compiler/exportDefaultEnumTargetES2015ModuleAMD.ts

@@ -0,0 +1,62 @@
+// https://github.com/Microsoft/TypeScript/issues/3792
+// @target: es2015


Our compiler runner supports test variations for the same source. Instead of multiple nnnTargetXModuleY.ts files you can do this instead:

Suggested change

// @target: es2015

// @target: es2015, es5

That would be nice, but it doesn't look like it's in yet?

Error: Unknown value 'es5, es2015' for compiler option 'target'.

rbuckton · 2019-02-06T20:18:50Z

tests/cases/compiler/exportDefaultEnumTargetES2015ModuleAMD.ts

@@ -0,0 +1,62 @@
+// https://github.com/Microsoft/TypeScript/issues/3792
+// @target: es2015
+// @module: amd


Our compiler runner supports test variations for the same source. Instead of multiple nnnTargetXModuleY.ts files you can do this instead:

Suggested change

// @module: amd

// @module: amd, commonjs, system, es2015

rbuckton · 2019-02-06T20:20:51Z

tests/cases/compiler/exportDefaultEnumTargetES2015ModuleAMD.ts

@@ -0,0 +1,62 @@
+// https://github.com/Microsoft/TypeScript/issues/3792


Consider adding these tests in a relevant location under tests/cases/conformance/** as tests/cases/compiler is extremely cluttered and unorganized.

Also, consider adding // @declaration: true to verify .d.ts emit and // @sourceMaps: true to verify source-map emit.

rbuckton · 2019-02-06T20:21:57Z

tests/cases/project/declarationsExportDefault.json

+        "namespace.ts",
+        "type.ts"
+    ]
+}


We are trying to avoid adding new "projects" tests in favor test variations in compiler/conformance tests. You can set // @declaration: true in the compiler/conformance tests to get .d.ts output.

TomasHubelbauer · 2019-04-25T09:05:45Z

Sorry for a dumb question, but does this add support for export default type? The diff is more than 1k files so I haven't really tried to figure that out from the changes.

RyanCavanaugh · 2020-01-08T21:06:43Z

Closing due to lack of activity here. Thanks for the work so far - if anyone would like to pick up on this feature, please do!

TomasHubelbauer · 2020-01-08T21:10:54Z

Is there an "authoritative" issue for people to subscribe to in order to be kept in the loop on this feature eventually dropping? This PR doesn't reference any issues as far as I can see and searching for export default and export default type returns 50 pages of results.

covers - "[abstract] class" - interfaces as per microsoft/TypeScript#3792 (comment) in 2020/12/15 other constructs (microsoft/TypeScript#18628 (comment)) are not yet supported by TypeScript itself

damianobarbati · 2023-01-11T11:34:00Z

@NaridaL why was this closed? Is there any chance of having export default type {}?

msftclas added the cla-already-signed label Sep 21, 2017

NaridaL commented Sep 21, 2017

View reviewed changes

msftgits removed the cla-already-signed label Sep 26, 2017

microsoft deleted a comment from msftclas Sep 27, 2017

mhegazy requested a review from a user November 8, 2017 17:57

ghost reviewed Dec 4, 2017

View reviewed changes

ghost mentioned this pull request Dec 19, 2017

[TypeScript]: Some syntax fails to compile when using an abstract class babel/babel#7060

Closed

simonbuchan mentioned this pull request Jan 11, 2018

[TypeScript]: Syntax error on "export default interface" syntax babel/babel#7118

Closed

NaridaL force-pushed the exportdefault_constenum_enum_declareclass branch from e309554 to 39b9cc3 Compare January 16, 2018 11:31

NaridaL commented Jan 16, 2018

View reviewed changes

rbuckton requested changes Jan 17, 2018

View reviewed changes

NaridaL force-pushed the exportdefault_constenum_enum_declareclass branch from 29a8fad to a0e3747 Compare January 20, 2018 21:32

NaridaL commented Jan 20, 2018

View reviewed changes

alvis mentioned this pull request Jan 30, 2018

Cannot 'export default' abstract, ambient class or interface #3792

Open

typescript-bot closed this Jun 13, 2018

ghost mentioned this pull request Jun 14, 2018

Add refactor to convert named to default export and back #24878

Merged

ghost reopened this Jun 14, 2018

RyanCavanaugh added this to the Community milestone Sep 17, 2018

Changed parser.ts to support all forms of export default described in m…

eb9025e

…icrosoft#3792 (comment). Added corresponding tests. NB: export defaults are not yet transformed correctly.

NaridaL force-pushed the exportdefault_constenum_enum_declareclass branch from a0e3747 to cdc7090 Compare September 23, 2018 12:41

NaridaL added 2 commits September 23, 2018 22:43

Modified ts.ts to handle export defaults enum/namespace correctly.

40a2312

fix message id

59c39e2

NaridaL force-pushed the exportdefault_constenum_enum_declareclass branch from cdc7090 to 59c39e2 Compare September 23, 2018 20:43

RyanCavanaugh assigned rbuckton Jan 24, 2019

rbuckton requested changes Feb 6, 2019

View reviewed changes

RyanCavanaugh closed this Jan 8, 2020

fabianlee1211 mentioned this pull request Feb 9, 2020

feat(react-native-appsflyer): complete definition DefinitelyTyped/DefinitelyTyped#42158

Merged

12 tasks

resolritter mentioned this pull request Dec 15, 2020

Support more of the export syntax tree-sitter/tree-sitter-typescript#125

Closed

		(token() === SyntaxKind.AbstractKeyword && lookAhead(nextTokenIsClassKeywordOnSameLine)) \|\|
		(token() === SyntaxKind.DeclareKeyword && lookAhead(nextTokenIsClassKeywordOnSameLine)) \|\|

		node.localSymbol = local;
		local.exportSymbol = declareSymbol(container.symbol.exports, container.symbol, node, symbolFlags, symbolExcludes);

		setTextRange(enumStatement, node);
		setCommentRange(enumStatement, node);

		@@ -0,0 +1,62 @@
		// https://github.com/Microsoft/TypeScript/issues/3792
		// @target: es2015

Allow export default const enum, export default enum, export default … #18628

Allow export default const enum, export default enum, export default … #18628

Conversation

NaridaL commented Sep 21, 2017 • edited Loading

NaridaL commented Sep 21, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

k8w commented Sep 25, 2017

mhegazy commented Nov 8, 2017

ghost left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

NaridaL Dec 4, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

NaridaL commented Jan 16, 2018

NaridaL commented Jan 16, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

NaridaL Jan 17, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rbuckton left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mhegazy commented Jan 18, 2018

NaridaL commented Jan 20, 2018 • edited Loading

Choose a reason for hiding this comment

NaridaL Jan 20, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

NaridaL Jan 20, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

NaridaL Jan 20, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

typescript-bot commented Jun 13, 2018

alvis commented Jun 14, 2018

NaridaL commented Jun 19, 2018 • edited Loading

alvis commented Jun 19, 2018

codetalks-new commented Jul 19, 2018

NaridaL commented Jul 19, 2018

codetalks-new commented Jul 20, 2018 • edited Loading

RyanCavanaugh commented Sep 5, 2018

NaridaL commented Sep 23, 2018

rbuckton commented Feb 6, 2019

rbuckton commented Feb 6, 2019

rbuckton left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TomasHubelbauer commented Apr 25, 2019

RyanCavanaugh commented Jan 8, 2020

TomasHubelbauer commented Jan 8, 2020

damianobarbati commented Jan 11, 2023

NaridaL commented Sep 21, 2017 •

edited

Loading

NaridaL Dec 4, 2017 •

edited

Loading

NaridaL commented Jan 16, 2018 •

edited

Loading

NaridaL Jan 17, 2018 •

edited

Loading

NaridaL commented Jan 20, 2018 •

edited

Loading

NaridaL Jan 20, 2018 •

edited

Loading

NaridaL Jan 20, 2018 •

edited

Loading

NaridaL Jan 20, 2018 •

edited

Loading

NaridaL commented Jun 19, 2018 •

edited

Loading

codetalks-new commented Jul 20, 2018 •

edited

Loading