You need to turn on synthetic default imports for it to work.

Would it make sense to change the import so consumers don't need synthetic default imports?

Certainly someone could take a look, but it's worth noting that not all npm packages support non-synthetic default imports, so it may actually be required.

Also worth noting that we haven't spent any time optimising any of the types across the repo for consumption outside of the repo.

Related: #330

esModuleInterop + allowSyntheticDefaultImports are the recommended standard options in the TS ecosystem now, see the TS 2.7 release notes, so I don't think any semantic change should be made here

That's fair. I know relatively little about what would need to be changed to make this work, and whether that'd break other users.

@adidahiya - whilst they are recommended, a lot of projects don't use them because they're not the default (yet?). So it might make sense to support not using them if it's not too much effort.

I haven't looked into it, but I think that it should be as simple as:

- import ts from 'typescript';
+ import * as ts from 'typescript';

If it's not that easy then I'll definitely drop it and instead opt for documenting the requirement on the options.

@bradzacher the problem is that it's hard to support both export styles in a published library, and I'd rather lean towards the future-facing syntax

edit: Yes, the code transformation for the breaking API change is as simple as that

If this would break people who don't use allowSyntheticDefaultImports then I agree that it's reasonable to just document 'by the way, you'll need this' on the README.md or someplace like it.

That change should work either way.

Looks like this issue should be closed? There's a merged PR from back in April

Thanks @crhistianramirez!