[lodash] type definitions don’t support auto-imports

[andrewbranch]

👋 Hello from the TypeScript team.

While investigating microsoft/TypeScript#31763, I discovered that individual lodash functions are actually written as methods on the LoDashStatic interface. So when a user writes

import { add } from 'lodash';

this is modeled as destructuring a method from a CommonJS export. We allow users to write this because it tends to work with bundlers and other ES module interop tools, but it’s a little iffy spec-wise, and we don’t offer auto-imports for members. Doing so would essentially be equivalent to something like this:

// a.ts
export = document.createElement('a');

// b.ts
focu// Want to add "import { focus } from './a'"?

It would be highly unusual to import members (especially methods) via destructuring, but that’s how the lodash typings are currently modeled.

I know there’s a build system and perhaps there are constraints and motivations around that, but it would be great if we could find some way to write each function as an exported function of a module or namespace instead of (or, in addition to, if necessary) an interface member.

Apologies if this has been discussed before, but I couldn’t find anything. Semi-related was #38326.

Pinging @bczengel @chrootsu @stepancar @aj-r @e-cloud @thorn0 @jtmthf @DomiR @WilliamChelman for thoughts, ideas, and maybe help implementing if possible 🌟 Thanks all!

[aj-r]

I'm not an expert in how the module system works so I'm not entirely sure what the solution is here.

I'm pretty sure that it was done this way before esModuleInterop existed, so at the time it was necessary to do things this way. If there's a better way of doing things now, I'm all for it, but I'd like to know what the side effects would be.

That said, lodash is a CommonJS package, so the typings need to reflect that. However, there is a separate package ('lodash-es') which has all the same functions, but uses ES6 modules instead of CommonJS - do auto-imports work for that package?

[andrewbranch]

I'm pretty sure that it was done this way before esModuleInterop existed, so at the time it was necessary to do things this way.

FWIW, my testing so far has been without esModuleInterop or allowSyntheticDefaultImports, but I think there may have been other related changes to the module system in the past. My assumption going into this is that a lot of care was put into designing the typings the way they are now, and things are probably going to be more complicated than they seem, but maybe there are new opportunities we can explore.

However, there is a separate package ('lodash-es') which has all the same functions, but uses ES6 modules instead of CommonJS - do auto-imports work for that package?

Yes! I thought I remembered some alternative like this. Good to know.

That said, lodash is a CommonJS package, so the typings need to reflect that.

Agreed. I think the conventional way to represent this would be like

declare namespace _ {
  function add(x: number, y: number): number;
  // ...
}

export = _;

...and now I realize the problem, probably the singular motivation for using an interface with members. You need the export to be callable (_([0, 1, 2]).map(x => x * 2)), and a namespace can’t be. 😕

[johnnyreilly]

Apropos of nothing, I think the Want to add "import { focus } from './a'"? is a very clear way to explain the situation. Props 🥰

[orta]

Hi thread, we're moving DefinitelyTyped to use GitHub Discussions for conversations the @types modules in DefinitelyTyped.

To help with the transition, we're closing all issues which haven't had activity in the last 6 months, which includes this issue. If you think closing this issue is a mistake, please pop into the TypeScript Community Discord and mention the issue in the definitely-typed channel.