Allow `import foo = require('bar');` syntax

On master, the import pLimit = require('p-limit'); is not allowed. I thought - well no big deal - I’ll run around to all the d.ts files that don’t support it, and submit a patch. Well - I got this feedback: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/33128

The guidance they provide links to a section here, which basically says to use synthetic default imports: https://github.com/DefinitelyTyped/DefinitelyTyped#should-i-add-an-empty-namespace-to-a-package-that-doesnt-export-a-module-to-use-es6-style-imports

Well - as we discovered - enabling synthetic default imports has consequences downstream, and cause all sorts of problems.

So I’m left in a bind here. I can’t use the import = require syntax without an exclusion, I can’t modify the d.ts to use the export namespace hack, and I can’t allow synthetic default imports.

I think we should lift this rule. Thoughts?

[BendingBender]

I know that synthetic default imports are very hacky, they fail if there default property isn’t exported. ES module interop, however, generates the missing default exports so that it kinda works but I’m not sure what happens when you build a lib like this and obviously it fails if your lib consumers don’t use this flag.

The canonical solution to this is to actually not use default exports when they’re not provided, not sure whether this actually helps in your case. An other technique is to manually export the thing that is exported via module.exports = ... as exports.default = ....

I would also ask people from the core TS team (andy-ms, sandersn, …), maybe they have a more helpful advice.

[JustinBeckwith]

Sure! So our team makes a bunch of libraries in TypeScript that folks use. At one point, we enabled --esModuleInterop in our tsconfig.json, and shipped a new version. The result was this: https://github.com/googleapis/google-auth-library-nodejs/issues/381

Setting --esModuleInterop resulted in side effects of the generated d.ts files that we ship with the module. If we exposed any of the types where we used interop, and the consuming user doesn’t have interop enabled, they get compilation bugs (as seen in the issue).

Now this is really only a problem for exported types that appear in the d.ts. We discussed the idea of leaving interop on, and leaving it to our dev team to know which packages were ok to import with interop syntax and which ones weren’t - but that makes it very easy for one of us to miss a mistake. In the end, we chose as a team to not enable interop or synthetic default imports for any of our projects.

Hope this is useful context Mr Rodriguez 😃