import * as alias syntax doesn't work with export = function unless merged with namespace

[weswigham]

declare module "foo" {
  function foo(): void;
  export = foo;
}

Can't be included via import * as f from "foo";.
(test.ts(1,20): error TS2497: Module '"foo"' resolves to a non-module entity and cannot be imported using this construct.)
Whereas

declare module "foo" {
  function foo(): void;
  namespace foo {}
  export = foo;
}

Can be. The distinction seems artificial.

[mhegazy]

there is no way in an ES6 module to achieve this. the parallel in an ES6 module world is to default export. import * will import the namespace component of the export, if it exists, if it does not, it is an error. That you can call the alias as a function in the second case, is the bug i would say.

[unional]

Without the hack, TS code cannot target es6 if it consumes cjs module.

With Babel, JS user is doing import x from 'x' and it is working fine for them.
For TS, right now we do not have any working solution except the hack.

[byrgvt]

I still can't tell if this was ever intended behavior or not (that using the namespace allows this to pass typecheck), or just a happy accident that now too many people rely on to change.n

It seems an empty namespace gets SymbolType NamespaceModule (1024) and the checker looks for the merged symbol. So basically

function C {} // symbol type 16
namespace C {} // symbol type 1024
(1024 | 16) & SymbolFlags.Module == true (from resolveESModuleSymbol in compiler/checker.ts)

is what I think is happening?

The PR that added module support #2242 explicitly mentions:

A module that uses export = to export a non-module entity in place of the module itself must be imported using the existing import x = require("foo") syntax as is the case today.

But I don't understand what typescript considers a non-module entity. The actual line in checker that flags these errors is:
(!dontResolveAlias && symbol && !(symbol.flags & (SymbolFlags.Module | SymbolFlags.Variable)))

So I can get away with pretty confusing stuff like:

a.ts
const x = () => 1;
export = x;

b.ts
import * as x from './a';

x()

Which passes compilation fine as with ./node_modules/.bin/tsc b.ts -t "es6" -m "amd".

Is a module entity related to https://www.ecma-international.org/ecma-262/6.0/#sec-module-namespace-exotic-objects, which is what the es6 grammar specifies is the type of import * as foo?

[qm3ster]

So, is this the hack?
And is it still the best way?

declare module 'nedb-core' {
	class Datastore {
		constructor(options?: {})
	}
	namespace Datastore {

	}
	export = Datastore
}

[LouisWayne]

@qm3ster I think so.. I don't like the consistency here..have you found any solution for this???

[qm3ster]

@LouisWayne well, the reason a hack might be the best we can do is because we are trying to ES6-import something that could never have been ES6-exported.
I am currently doing what I wrote above and not having any problems.

[unional]

With esModuleInterop available, you should not need this hack anymore.
You should be able to do:

import x from 'cjs'

// instead of 
import * as x from 'cjs'

[aodinok]

Thanks! esModuleInterop works like a sharm!