Jay Phelps

the latest issue with autobind and TypeScript is most likely related to the way they polyfill classes being different than babel, rather than differences in the decorator implementations. That's just...

hmm that's odd indeed. Generally the emitted runtime code looks to same for imports/exports AFAICT. I'm guessing it's a type thing maybe? Are you including `@types/chai`? I'm not super familiar...

Wow they don't check for __esModule interop?? They even emit the __esModule: true code on their exports! That's silly. Your * as chai solution sounds good and has the same...

@BurtHarris it appears (but I haven't confirmed) that in TS the `allowSyntheticDefaultImports` option is needed to get the same CJS "default" import fallback as babel.

Very nice!! I see they even responded and even [discussed in their latest meeting](https://github.com/Microsoft/TypeScript/issues/16093).

@BurtHarris hmm I definitely don't want to maintain two versions, one in TS and one in babel. 😢

@BurtHarris what all is left to merge the index.d.ts with the actual source files so we don't need to maintain both? i.e. build from TS which will generate the actual...

@BurtHarris the `es` directory is supposed to contain ES5.1 code except using ES modules instead of CJS. If I were to redo it today, I would have named the directory...

@BurtHarris sorry for the delayed response, did you figure it out? Here's an example taken from an internal library I have that does this: ``` "build": "npm run build:es2015 &&...

I too wondered about this. @lachlansneff do you know of any previous or further discussion around this online or in the meetings?