Definitelytyped: 4.14.38 lodash @typings break the global dependency handling in typescript 2.0

[ashubham]

I tried using the latest @typings/[email protected] module from the npmjs. I use lodash as a global in my app. But after the latest update my compilation breaks with:

error TS2686: Identifier '_' must be imported from a module

[mohsen1]

I think if you use _ globally you should declare it yourself instead of depending on type definition

import lodash from 'lodash';
declare const _ = lodash;

[ashubham]

@mohsen1 I do not have an actual code module for lodash. I just want to use the types.

doing import lodash from 'lodash' will put lodash as a hard dependency for the concerned module.

[mohsen1]

You can use webpack externals for that

[ashubham]

Is there a systemJS equivalent ?

[vvakame]

cc/ @mhegazy
maybe related to #12361 ?

[cttobin]

I assume these type definition files are trying to match the same major and minor versions of Lodash (unless it's an incredible coincidence that they are the same), but that doesn't really work well with NPM. Something in the change from @types/lodash from v4.14.37 to v.4.14.38 causes a problem if you have this in your package.json (the default if you install with --save-dev):

"devDependencies": {
     "@types/lodash": "^4.14.37"
}

or

"devDependencies": {
     "@types/lodash": "~4.14.37"
}

Then npm install will install v4.14.38, which in my case broke my application when it was deployed to a test environment due to this TS2686 error.

Really, to suit the way NPM works by default, https://github.com/DefinitelyTyped/DefinitelyTyped/pull/12361 probably should have updated @types/lodash to v5.0.0 because it is a breaking change. But I suppose that doesn't work with your current versioning.

[mohsen1]

I'm curious to know what's the policy for versioning type definition. Unless the change is addition of an optional property to some interface it's a breaking change and should be a major new version in my opinion.

[mhegazy]

I'm curious to know what's the policy for versioning type definition. Unless the change is addition of an optional property to some interface it's a breaking change and should be a major new version in my opinion.

The major and minor version matches that of the package. the build is what changes with every change. We try to have no breaking changes. but this specific issue is a bug fix that is needed to enable other scenarios that were broken.

[mischkl]

After adding the suggestion from @mohsen1 it still doesn't work, TypeScript still complains error TS2686: Identifier '_' must be imported from a module. TBH this seems like a new bug, if there is no working workaround.

[cttobin]

@mischkl I fixed it by importing the functions I need from Lodash in each file. E.g.

import { filter, reject } from 'lodash';

You might not want to do that, but I did personally because I never liked using the global types anyway.

[mischkl]

In a large existing codebase that is a lot to ask..
I managed to at least get it to compile without errors by adding

declare const _: any;

but that kind of defeats the point of the typings...

[Delagen]

import {every} from "lodash";

TS2307:Cannot find module 'lodash'.

Issue is when types not installed locally, and when imported manually through typeRoots and types properties from tsconfig.json

[Delagen]

Any news?

[maartentibau]

Would be nice if there was a real solution for this, instead of needing to use something like.

declare const _: any;

[ronanquillevere]

Hi, having the same kind of problem, I am maybe doing something wrong but I cannot find what. Any help would be greatly appreciated. I am Using typescript 2 + jspm. I think I tried all the possibilities inside the tsconfig using typeRoots and types (adding the version number in the name of the type). My current config is the following and it is not working whereas I think it should...

package.json

  "jspm": {
    "dependencies": {
      "lodash": "npm:lodash@^4.17.4"
    },
    "devDependencies": {
      "@types/lodash": "npm:@types/lodash@^4.14.45",
      "babel": "npm:babel-core@^5.8.24",
      "babel-runtime": "npm:babel-runtime@^5.8.24",
      "core-js": "npm:core-js@^1.1.4",
      "systemjs": "npm:systemjs@^0.19.41"
    }
  }

tsconfig.json

"typeRoots": [
  "jspm_packages/npm/@types"
]

Then compiler does not understand

import * as _ from "lodash"

I get

Cannot find module 'lodash'.

as suggested by the typescript doc https://www.typescriptlang.org/docs/handbook/declaration-files/consumption.html

Now if I remove the import, the funny thing is that vcode is able to go find the merge method definition (F12) if I write the following line of code, but compiler still complains that

_.merge(a, b);

Identifier '_' must be imported from a module

So solution by @mohsen1 does not work as lodash module is not found. Any solution ?

[Delagen]

Any news ? So difficult to declare module in definition as was before 38?

[Delagen]

@ronanquillevere
This occur that in typings removed module declaration, but left global variable declaration. Very sad.
People use lodash and typescript not only for browser environment, but also in node.js development.
Please restore module declaration in typings as it was before 4.14.38
At least

declare module "lodash" {
    export = _;
}

[andy-ms]

The original topic is Microsoft/TypeScript#10178.
@ronanquillevere Try using --traceResolution to see where TypeScript is looking for lodash.
@Delagen @types/lodash is already declared as a module, since export = _ appears at the top-level.

[Delagen]

This does not work in types mode, try to install and use

[andy-ms]

@Delagen What is "types mode"? I am able to install and use @types/lodash.

[Delagen]

@andy-ms
Found test config
See project https://github.com/Delagen/lodash-typescript-issue
Main issue that types is located at another path, if all in one project, that works.
But i use single project where I store all dependencies used with more than 30 others related

[andy-ms]

@Delagen The problem there is --typeRoots is only for type references, not for imports. If you really want to import modules from an unusual location, you will have to use --baseUrl or path mapping.

[Delagen]

@andy-ms earlier typings have multiple declare module blocks which makes it work for all use cases. I found workaround solution for me, but sure that typings supplied separate from source must work in all situations

[andy-ms]

We actually want to be declaring types locally and not globally and storing them in the same node_modules as the module itself. So if you use lodash v3 at one place and lodash v4 at another place, we can resolve both imports. So in the situation where you are storing types in an unusual directory, you need to tell TypeScript to look there instead of in node_modules.

[Delagen]

@andy-ms I think it's not the same, and can do some issues in some situations, where typescript extension use paths module resolution for rewriting imports. For example: angular compiler
See types/jquery for example: declare module "jquery"
More https://www.typescriptlang.org/docs/handbook/tsconfig-json.html @types, typeRoots and types section contains example that not works after 4.14.38

{
   "compilerOptions": {
       "typeRoots" : ["./typings"]
   }
}
{
   "compilerOptions": {
       "types" : ["node", "lodash", "express"]
   }
}

So lodash won't work in this

[andy-ms]

OK, I've created an issue for updating docs.

[Delagen]

Created repo https://github.com/Delagen/types-lodash with compiled version that support ambient mode

[ikewabo]

Adding @ types / lodash to package.json fixed it for me.