Unexpected behavior when transpiling console interface from @types/node

[traviskaufman]

tsickle version: 0.2.2
typescript version: 2.1.4

Given this tsconfig.json:

{
  "files": ["index.d.ts"]
}

And this slimmed down example of @types/node's index.d.ts:

interface Console {
  Console: typeof NodeJS.Console;
}

declare namespace NodeJS {
  export var Console: {
    prototype: Console;
  }
}

Running tsickle --externs=externs.js produces the following output for me in externs.js:

/**
 * @externs
 * @suppress {duplicate}
 */
// NOTE: generated by tsickle, do not edit.
 /** @type {?} */
Console.prototype.Console;
/** @const */
var NodeJS = {};
 /** @type {?} */
NodeJS.Console;

Notice how the initial Console statement is omitted.

---

However, if I simply change the interface names in index.d.ts:

interface Foo {
  Foo: typeof NodeJS.Foo;
}

declare namespace NodeJS {
  export var Foo: {
    prototype: Foo;
  }
}

Running the same command gives me the following externs.js:

/**
 * @externs
 * @suppress {duplicate}
 */
// NOTE: generated by tsickle, do not edit.

/** @record @struct */
function Foo() {}
 /** @type {?} */
Foo.prototype.Foo;
/** @const */
var NodeJS = {};
 /** @type {?} */
NodeJS.Foo;

Notice how the initial function Foo() statement is not omitted.

---

The full reference file can be found at https://github.com/DefinitelyTyped/DefinitelyTyped/blob/types-2.0/node/index.d.ts. Looks like this also happens for builtins like ErrorConstructor. Could this be because we're assuming that closure is operating with --env BROWSER and therefore we don't want to overwrite these globals?

[evmar]

I think it's this logic:

tsickle/src/tsickle.ts

Line 992 in d3bb689

if (this.isFirstDeclaration(decl)) {

The question is, who is declaring Console first? And I think the answer is that it's declared in the TS standard library, so tsickle is assuming that it's also declared in the Closure standard library.
https://github.com/Microsoft/TypeScript/blob/7da338350406f60e9bb26ea0ad0ee8d97e12fd4e/lib/lib.d.ts#L6082

We have some other workarounds related to guessing whether a type is from the standard library or not, see

tsickle/src/type-translator.ts

Line 31 in d3bb689

function isClosureProvidedType(symbol: ts.Symbol): boolean {

. It's a horrible hack but maybe it could at least be reused in the above logic.

Edit: so I think the solution is to change the isFirstDeclaration logic to only count declarations that are not in the TS standard library. However, you'll probably need to experiment to see whether Closure accepts it.

[traviskaufman]

Thanks for that info! Using it, I was able to get it to compile correctly.

tsickle --externs=externs.js -- --lib es2015

yields

/**
 * @externs
 * @suppress {duplicate}
 */
// NOTE: generated by tsickle, do not edit.

/** @record @struct */
function Console() {}
 /** @type {?} */
Console.prototype.Console;
/** @const */
var NodeJS = {};
 /** @type {?} */
NodeJS.Console;

Should this lib-checking behavior be something that should go into documentation?

[evmar]

This definitely belongs in the docs! I don't actually know what your command-line did, can you explain it? I guess when you pass --lib it's changing the default set of built-in libraries?

Also, does that resulting code actually work in Closure? Or does it reject the code due to the redeclaration of Console?

[jvilk]

Would this bug / limitation cause this error?

Parameter 'buff' of exported function has or is using private name 'Buffer'.

I tried throwing tsickle at my BrowserFS library, in the interest of seeing if the CC can shrink my minified builds further, and it throws a bunch of those errors. (If you feel like reproducing: Just clone, npm install, and run tsickle in the src directory.) BrowserFS emulates the Node fs module, so it pulls in Node's types for typechecking and uses a Buffer polyfill.

Thanks for making this tool. Would be neat to use it at some point.

[mprobst]

Would this bug / limitation cause this error? Parameter 'buff' of exported function has or is using private name 'Buffer'. No, that's a different issue. It happens if you try to create a .d.ts file

from a .ts file that exports something, but the types used in the export are not public. You can fix that by exporting `Buffer`.

[trusktr]

Regarding the all-too-common "has or is using private name" error, I've opened a request to fix issues like these in TypeScript by bringing declaration files to parity with language features. microsoft/TypeScript#35822

[evmar]

To resummarize this thread based on current behavior:

• tsickle assumes that browser builtin types are already handled in closure externs
• nodejs attempts to declaration merge with Console
• but closure externs don't define Console (I think?)

If that is the case, then the small fix is to add Console to the closure externs (or tsickle's closure externs js file).

But the larger picture is that you don't want to closure compile node code anyway because it is unlikely to work, so I think we are unlikely to fix this.