Added exports for chai extensions

[olivr70]

Changes required for the chai-as-promised type definition

[blakeembrey]

This change can't be accepted, it's not correct.

[blakeembrey]

I think this can be merged it you don't use this and remove the Chai interface instead actually. cc @unional, does that sound right?

[unional]

Sounds good. The other things is about the tslint. The format might be a bit off.

[blakeembrey]

@olivr70 The changes can not be accepted because you're changing to export incorrectly.

@unional The changes make sense, it would be good to have some proper refactoring to not export an interface as the main and instead have multiple exports. Currently nothing can be augmented for re-used because of the type definition structure.

[blakeembrey]

use (fn: ChaiExtension): Chai? I'd also move this to the main export to be able to kill the Chai name. It'll then look like import * as Chai from './lib/Chai'.

[olivr70]

Thank you for your comments. As you have guessed, I am rather new to this ecosystem.

The olivr70/typings-chai-as-promised project references my version of npm-chai, compiles and runs multiple mocha tests (in the test folder : just clone and run npm test).

I don't understand why "export default chai;" is not correct (it is compiled by the Typescript compiler)

My problem for chai-as-promised are :

• that I have to augment inner modules whose naming is linked to typings implementation details (like ~chai/lib/Assert)
• is has to be an ambient module to augment the ambient modules generated by typings

[unional]

Definitely should have multiple exports. When I port them I focus on cleaning up and expose the core shape.

[unional]

I don't understand why "export default chai;" is not correct

That is because the source package (chai) is a commonjs and export as modules.export =.
export default is ES6, which chai is not a ES6 package.

[unional]

that I have to augment inner modules whose naming is linked to typings implementation details (like ~chai/lib/Assert)

Unfortunately I think currently TypeScript 1.8 has a bug on the module augmentation, so it might not work.

[olivr70]

@blakeembrey about the export default chai; I get the argument that this is ES6 style, but because we are writing a .d.ts file, this will be used only by the Typescript compiler and never appear in the generated .js file.

And the Typescript spec (section 11.3.4.2 does not mention any limit to using default.

Am I missing something ?

[unional]

@olivr70 , it's a whole can of worms. Don't go there: microsoft/TypeScript#7398

[blakeembrey]

I get the argument that this is ES6 style, but because we are writing a .d.ts file, this will be used only by the Typescript compiler and never appear in the generated .js file.

If you write a definition that does not match the source code, you can never expect runtime to actually work. By writing it incorrectly, people won't be able to actually use the definition. At least, they will, but not until they actually try to run their code.

[blakeembrey]

For example, if you say the source code is export default (because that's what a .d.ts, the typed .js) then people need to use import chai from '' syntax. However, once it goes to runtime land it all explodes because Chai does not have an exported member called default.

[blakeembrey]

Here's a simple example: http://www.typescriptlang.org/Playground#src=export%20default%20function%20()%20%7B%7D%3B. Notice exports.default = default_1 in the generated code. That's the equivalent here. If you try to do that to Chai, which does not have a exports.default, the runtime (JavaScript) will never run because .default is not a property on the Chai export. Does that help?

[unional]

@olivr70 are you working on another PR? I can re-work it to expose the interfaces.