If I want to support lodash submodule about types-2.0, how do I do?

[TonyPythoneer]

@andy-ms I have a question. If I want to implement types as the same #12220 PR for lodash.

Follow types-2.0 procedure, it means I need to create multiple directories to express each sub module. Should it be like this following?

DefinitelyTyped
  |- lodash.after
  |- lodash.ary
  |- lodash.assign
  |- lodash.assignIn
  ...

[ghost]

A subdirectory lodash/after already exists. This is published as part of the @types/lodash package. We certainly wouldn't want to publish a different @types package for every lodash function.

[TonyPythoneer]

I know building subdirectory on DefinitelyTyped doesn't be allowed.

I am confused how to implement lodash.after for types-2.0.

[ghost]

Sorry, I didn't realize that both lodash/after and lodash.after exist. I'm still not sure if we would want to publish @types/lodash.after, @types/lodash.ary, etc., but it's a possibility.

[TonyPythoneer]

Although creating @types/lodash.xxx is possible, it will cause high maintain and management cost.

Suppose lodash.after will be deprecated in the future, we can easily and directly delete lodash/after file. When lodash.after exists, the contributor needs to do the same work to maintain the lodash.after. It's not convenience.

If you think this is okay, I will send PR about it.

[ghost]

Give me some time to discuss with others. @RyanCavanaugh @mhegazy

[ghost]

We've decided that we don't want to host a package for every lodash function. But, you can add declare module "lodash.after" declarations to the existing lodash typings.

[TonyPythoneer]

Great! I got it.

[stephenlautier]

@TonyPythoneer how do you exactly intend to use them at runtime with any module loader?

e.g.

import kebabCase from "lodash/kebabCase";

works perfectly for TSC (thanks to you 👍) .. however now im struggling to get it working at runtime. Have you tried it with rollup, system or anything? If so how are you using them?

These are the errors im getting...

Rollup error: 'default' is not exported by node_modules\lodash\kebabCase.js

Aurelia cli error: no such file or directory, open '/experimental\au-proj\node_modules\lodash\lodash\kebabCase.js'

Of course they fail, because lodash doesnt have lodash/kebabCase.js directly. Its either lodash/string/kebabCase.js or lodash-es/kebabCase.js. With systemjs probably i can get it working quite easy as i would map to lodash-es instead, however i just started to experiment with rollup so its a bit harder for me atm.

Any help out be really appreciated, thanks!

[TonyPythoneer]

@stephenlautier Ummm...., I don't know what you're talking about? Is it related to this issue?

If you want to ask module loader, I only use commonjs style.

The lodash doesn't use export.default to export any function, so you offer example is surely failed.

[stephenlautier]

@TonyPythoneer sorry, it might not be the best to ask; however its somewhat related to typings as well. Perhaps if I had left it within the PR it was a bit more appropriate.

I'm simply asking how were you planning to use the typings you defined with a module loader, since if you simply install lodash and @types/lodash they wont work. As I previously stated lodash/kebabCase wont resolve correctly by default, without any quirks (at least from what I understood/tried).

[TonyPythoneer]

@andy-ms I found it's not available for types-2.0 style because the module name is decided by folder name. If it will implement lodash.xxx, it really needs to build lodash.xxx folders.

Because I had surveyed other type definitions such as master/react, it had originally react, react-dom, etc. When checking out on types-2.0/react, it has only index.ts for react, and react-dom has its own folder.

So, I think building multiple folders are necessary. :cry:

[TonyPythoneer]

@stephenlautier Finally, I understand what you are talking about.

You can use this:

import kebabCase = require("lodash/kebabCase");
kebabCase(...);

It's because it exports function ,not default. Please try to the demo, I think it will be okay.

I hadn't plan that because I don't know why I have to do.

[ghost]

@TonyYang Ambient module declarations still work in TypeScript 2.0, it's just not the preferred style for definitions that declare a single module. You can create a file lodash/modules.d.ts containing:

declare module "lodash/add" { export = _.add; }
declare module "lodash.add" { export = _.add; }
...etc...

Just add /// <reference path="modules.d.ts" /> to the top of lodash/index.d.ts, and people should now be able to use:

/// <reference types="lodash"/>
import add1 = require("lodash.add");
import add2 = require("lodash/add");

[ghost]

@stephenlautier You probably have "allowSyntheticDefaultImports": true. This turns off a compiler warning telling you exactly what rollup tells you: it doesn't have a default export. Try using import kebabCase = require("lodash/kebabCase"). Also, my npm install lodash installs node_modules\lodash\kebabCase.js, so the typings are accurate relative to an NPM install -- did you get yours differently?

[stephenlautier]

@andy-ms oopps! appologies, you are right lodash is as you stated, i was messing with lodash-es and with devDeps it installed me lodash 3.x :( facepalm and i think you are probably right with the syntetic.

My target is to use lodash and treeshake it, i believe then my best bet is to use lodash-es and provide typings for that, since module name mismatch and they need to be defaults