mem intellisense broken for JS

This issue matches PR #30. I think it’s better to have a discussion here.

I believe this issue applies to all your packages that recently added types via d.ts files. I assume that the purpose was to improve intellisense. Right now, it works fine for Typescript users who have --esModuleInterop turned on, but for normal JS use it’s broken:

const mem = require('./mem')

isn’t callable, even though the primary export of this package is a function.

Instead, people have to change their code to

const mem = require('./mem').default

which seems like it goes against the normal commonjs usage.

The d.ts file seems like it exists solely to provide better intellisense, and it consists solely of typescript syntax, so I think using the typescript syntax for commonjs exports make sense. That way people who use mem in editors with intellisense will not have to add .default to all their existing require('./mem') calls.

[BendingBender]

There are 2 options:

// 1st
import foo = require('foo');

const fooVal: foo.Foo = ...;
foo.namedExportFn();

// 2nd
import foo = require('foo');
import {namedExportFn, Foo} from 'foo';

If your default export is a class the whole definition becomes much more awkward:

declare namespace Foo {
	// Only interfaces may be declared here. If you have a value,
	// you'll need to declare it as a static member on the class
	// or via an intersection type.
}

declare class Foo {}

export = Foo;

[weswigham]

Why wouldn’t mem be directly callable provided @sindresorhus moves his modules to ESM, which he plans to do?

As I said, if both consumer and producer are esm, it’d work fine, but if mem is still cjs (eg, because a consumer’s dependency is locked to this version), the default member of the default import is what’s going to be needed to work (according to the type definitions).

Lemme be blunt with y’all: DO NOT WRITE DECLARATION FILES TODAY FOR TOMORROW’S NODE ESM IMPLEMENTATION.

1. How it works is still in flux. What you think works today might not tomorrow, or there may be a better way tomorrow.
2. Because of how it’s likely to work at present, we (as in TS) will likely need to augment declaration files with some kind of “node-esm-only” marker (since it behaves very differently than the transpiled esm es syntax in a declaration file represents today, and we’ll need to flag it’s usage from commonjs). We’ll be deciding how that works once everything interop wise is decided and it’s about to unflag, which is optimistically October. So any declaration file written today will, ofc, not have that marker.
3. Declarations that don’t accurately reflect (current) reality are dangerous. Ultimately that means incorrect intellisense results, and a drop in type coverage for a program.