Definitelytyped: Lodash All declarations of 'WeakMap' must have identical type parameters.

Some more info: Targeting es5 with "lib":["es6", "scripthost", "dom"] seemed to be causing my issue. The ES6 declaration conflicts with this global declaration. Removing the global definition allows our project to compile. It seems like bad practice to include global definitions in a module...

Author mention: @bczengel - Thanks!

I only seem to get this error from angular-seed-advanced's build.js.dev gulp task. When I run tsc using the same options as the task:

{
  'target': 'es5',
     'module': 'commonjs',
     'declaration': false,
     'removeComments': true,
     'noLib': false,
     'lib': [ 'es2016', 'dom' ],
     'emitDecoratorMetadata': true,
     'experimentalDecorators': true,
     'sourceMap': true,
     'pretty': true,
     'allowUnreachableCode': false,
     'allowUnusedLabels': false,
     'noImplicitAny': false,
     'noImplicitReturns': true,
     'noImplicitUseStrict': false,
     'noFallthroughCasesInSwitch': true,
     'typeRoots': [ '../../node_modules/@types', '../../node_modules' ],
     'types': [ 'node', 'jasmine', 'protractor', 'systemjs', 'hammerjs' ] },
  'exclude': [ 'desktop', 'nativescript', 'node_modules', 'dist', 'src' ],
  'compileOnSave': false 
}

I don't get the error.

This problem seems to be arising because of changes in the TypeScript compiler.

Using

• @types/node v6.0.52
• @types/lodash v4.14.44

I was able to compile with:

• typescript v2.2.0-dev.20161229

But I could not compile with

• typescript v2.2.0-dev.20170201

I believe the problem lies with @types/lodash (for its mis-matching WeakMap interface). It's just that previous versions of TypeScript did not catch the error

Do you use yarn? I have run into exactly this error using yarn to install my deps. When using npm, all is fine.

EDIT: turns out npm resolved to an older version of typescript than yarn. So my problem is consistent with what @eschwartz reported.

I also used yarn to install initial dependencies.

My issue was with the latest version of Typescript, same as @eschwartz. I use npm.

The definition of WeakMap has recently changed in lib.es6.d.ts (the PR is here). In TS v2.1 it is:

interface WeakMap<K, V> {

But in the current nightlies it has changed to:

interface WeakMap<K extends object, V> {

The stub in lodash.d.ts does not match this new definition. The long-term fix is to change the WeakMap stub in lodash.d.ts to match this new definition. But in the short term that will not match the current production version of TS (v2.1). ¯\_(ツ)_/¯

Can we make the fix in @types/lodash, in anticipation of the TypeScript lib.es6.d.ts change? It seems like it would be best to remove the WeakMap interface from @types/lodash altogether.

I'm just not sure how updates and versioning works with types within DefinitelyTyped. Can someone give me some guidance?

@bczengel, @chrootsu, or @stepancar -- could you share you thoughts on this issue?

Is a fix available?

Or maybe a temporary workaround ?

the workaround I'm using is to comment out the weakmap definition:

file: node_modules\@types\lodash\index.d.ts

// Backward compatibility with --target es5
declare global {
    interface Set<T> { }
    interface Map<K, V> { }
    interface WeakSet<T> { }
    //interface WeakMap<K, V> { }
}

Thnx @nippur72

Thanks, @budiadiono!

the workaround I'm using is to comment out the weakmap definition

It's generally not a great idea, to modify files in node_modules. Yes, it will build, but it anyone else tried to download your code and run a build, it will fail for them (assuming your node_modules are not committed).

The workaround I found was to use an earlier build of TypeScript. I do not believe this is an issue for any official release of TS (yet). So you shouldn't have any problems if you're using TS v2.1.4. And as I said earlier, I found this bug with TS v2.2.0-dev.20170201, but not with v2.2.0-dev.20161229.

IMO, the best workaround is to "skipLibCheck": true

Once fixed you can remove it.

+1

IMO, the best workaround is to "skipLibCheck": true

I found this about the skipLibCheck option. I'm still not totally clear on how it works, but it does act as a workaround for this issue.

@eschwartz my fix breaks backward compatibility, since the object type is just introduced in new ES6 which is now in RC version. Since these ES6 changes is now in RC version, there's nothing we can do about it. I think @shlomiassaf workaround to "skipLibCheck": true is the best idea.

Can't we use version control, to manage backwards-breaking changes? I mean, publish a @types/lodash package with a major version bump (eg v2.0.0)?

if it's really going to break with old TS versions, we'd be breaking semver to release as v1.x....

You mean v5? "@types/lodash": "^4.14.52",

Proper versioning of typing is really problematic.

We have library version, typescript version, and typing version :)

For example i use "lodash": "^4.17.4",, and i should use @types/lodash v5? it's non intuitive :(

I can suggest something like in scala: libraryVersion_typingVersionForThisLibraryVersion_typeScriptVersion.

Example: @types/lodash: ^4.17_1_2.1 but it's ugly and has many other problems.

what about "@types/[email protected]": "^1.23.4"?

Yea, i like, btw npm install @types/[email protected] cause installing of @types/lodash - vesrion 2.2.0, so there are should be other symbol, like underscore:

@types/[email protected] - where patch version is version of typing. This should works well for all packages which preserves semver.

@types/lodash/2.2.0 ?

Whatever the next version number is, it needs to follow semver, in order for it to work properly with npm.

Yes, versioning is confusing for typings. And having all of these typings in a single DefinitelyTyped repo makes versioning much more difficult to understand.

But the bottom line is that if we break backwards compatibility, we need a major version bump. So you make the change, bump the @types/lodash version to v5.0.0, and write in the Changelog:

- Add support for TypeScript v2.1.5
- **BREAKING** No longer support TypeScript <v2 (or whatever it is)

@eschwartz sorry, i can't agree with you, different versions of typings and library confusing, and complicates search of right version.

Semver needs to be followed in order to not push a breaking change to unsuspectingly to users. Lodash had a hack to make it work, now that hack is breaking newer versions of other things. Major version bump.

EDIT: Versions are free, @types is already a different version number than the lodash version number it supports, why NOT major version bump?

You don't have to agree with me, I'm telling you that if you break semantic versioning, it's going to cause problems. Unless you make a major version bump, people are going to npm install on the _same_ package.json two different times, and their code will build one time, and not the next.

We use semantic versioning for a really good reason.

@sanex3339 -

what about "@types/[email protected]": "^1.23.4"?

Will not work with npm. When someone goes to install via npm and do npm install @types/[email protected] it's going to try and install version v2.2.0. @ is a reserved character before a version number like that.

@four43 @eschwartz so you trying to put three different versions in one, as i say earlier - it will be bad decision, just like ignoring semver.

In scala same problem solved by this version pattern:

@types/[email protected]

I think this is one of acceptable solution, bumping major version, just like ignoring semver should be avoided.

@types/lodash_2.2.[email protected]

You could do something like this... but then are you going to publish a new npm package for every version of lodash? And what about cases where the version of TypeScript is relevant (like in this partical issue)?

Anyways... we're pretty far off topic here. Maybe we should open a new issue about versioning with DefinitelyTyped?

... so you trying to put three different versions in one, as i say earlier - it will be bad decision, just like ignoring semver.

I think having versions like this all wrapped into one is just inherently difficult. We're trying to keep track of typescript, lodash, and this library all together. When any of them make a breaking change do you update major version? Semver says yes. Which is kind of a bummer if you have to maintain older versions. The broader DefinitielyTyped community may have a better solution? Hopefully?

Thanks for your feedback, @IRus.

@eschwartz not for every version of lodash, but for every breaking-change version of typescript itself. So we will have matrix of versions of course, and of course it difficult to maintain. But bumping version doesn't address this problem at all.

@typings/ should be following the latest versions of typescript first

Ah, so in @types/[email protected], the 2.2.0 was referencing the version of TypeScript. I didn't get that.

I'm wondering -- what's the big aversion here to just using standard semver and changelogs to indicate breaking changes? This is not a unique problem, to have libraries that need to update in track with another libraries. For example, we don't see a lot of folks in the node community doing things like [email protected] to indicate that it requires node v4.4.3. That would start to get really confusing really fast.

And can I give another call out to @bczengel, @chrootsu, or @stepancar --- it would be really helpful to have your input on this. Can we remove the type global WeakMap type altogether from @types/lodash? That would surely be simplest solution, if it doesn't cause problems elsewhere.

@eschwartz we can not remove type global WeakMap because it will breaks backward compatibility with ES5. ES5 doesn't have WeakMap declaration. Instead of removing it maybe we can do dirty thing like rename interface WeakMap to WeakMapES5. I've made pull request for it. Finger crossed :)

Instead of removing it maybe we can do dirty thing like rename interface WeakMap to WeakMapES5

That sounds like a good idea -- essentially, a workaround to allow @types/lodash to use the WeakMap interface, while keeping it out of the global scope.

And having all of these typings in a single DefinitelyTyped repo makes versioning much more difficult to understand.

Join discussion on:
https://github.com/Microsoft/types-publisher/issues/4

to move things forward.

With indirect, you can propose to support this by specifying it in package.json. e.g.:

{
  "version": "<typings version>",
  "sourceVersion": "<version>",
  "engines": {
    "tsc": "<version>"
  }
}

Now that 2.2.1 has been marked as latest, this is blocking compilation without skipLibCheck 😢

Alot of discussion here and many references. Is there a permanent fix or nice workaround available? I'm getting this error since upgrading to latest typescript:

ERROR in [at-loader] node_modules\@types\lodash\index.d.ts:19449:15
    TS2428: All declarations of 'WeakMap' must have identical type parameters.

Manual editing of .d.ts file is not a viable workaround for me.
I'm not referencing this lib myself, it's a third party reference to @typesloadash

@mikeesouth I'm on typescript 2.2.1 and lodash:
"lodash": "^4.17.4", "@types/lodash": "^4.14.58"
Verify you are on the latest versions - I would suggest creating a PR on the 3rd party or trying with including the lodash on your package.json.

@ShaharHD ah, thanks. I'm not using lodash myself and I didn't see it helping when I included "@types/lodash": "^4.14.58" but apparently I misread the output/result. When I include that version specifically my build works again. Case closed (for me at least).

* NG Live Development Server is running on http://localhost:4200. *
Hash: 86bc52fb2902aa628a4b
Time: 21576ms
chunk {0} polyfills.bundle.js, polyfills.bundle.map (polyfills) 232 kB {5} [initial] [rendered]
chunk {1} main.bundle.js, main.bundle.map (main) 260 kB {4} [initial] [rendered]
chunk {2} styles.bundle.js, styles.bundle.map (styles) 174 kB {5} [initial] [rendered]
chunk {3} scripts.bundle.js, scripts.bundle.map (scripts) 435 kB {5} [initial] [rendered]
chunk {4} vendor.bundle.js, vendor.bundle.map (vendor) 4.55 MB [initial] [rendered]
chunk {5} inline.bundle.js, inline.bundle.map (inline) 0 bytes [entry] [rendered]

ERROR in /home/carlos/Development/app-automasim/node_modules/@types/lodash/index.d.ts (19417,15): All declarations of 'WeakMap' must have identical type parameters.)

@duard had the same problem.
"lodash": "4.17.4",
"@types/lodash": "4.14.58",
"typescript": "~2.1.0",
fixed it.
Using TS >2.2 is causing the error on my side.

I had to upgrade not only @types/lodash but also @types/core-js to 0.9.39 to get rid of this error. Turns out the core-js typings also has a WeakMap definition which made [email protected] complain about the lodash typings even though it was upgraded to 4.14.59, not very obvious...

Now this works:
[email protected]
@types/[email protected]
@types/[email protected]

There are still two packages that seem to mention in, including es6-shim, which was the real culprit in my case:

% grep -r "interface WeakMap<K, V>" types
types/es6-collections/index.d.ts:interface WeakMap<K, V> {
types/es6-shim/index.d.ts:interface WeakMap<K, V> {

I jury-rigged a fix in node_modules for myself (as right now I'm only doing exploratory work that doesn't matter much), but I don't really fully understand why it was in es6-shim in the first place (actual es6-shim doesn't implement weak maps), so I'm hesitant to make PRs.

@erikbarke: I have tried the same versions as you have mentioned but no success. Still getting below errors:

TS2304 Cannot find name 'object'
TS2428 All declarations of 'WeakMap' must have identical type parameters.

Below is my package.json:

{
  "version": "1.0.0",
  "name": "hrplatform",
  "private": true,
  "dependencies": {
    "@angular/common": "^2.4.10",
    "@angular/compiler": "^2.4.10",
    "@angular/core": "^2.4.10",
    "@angular/forms": "^2.4.10",
    "@angular/http": "^2.4.10",
    "@angular/material": "^2.0.0-beta.2",
    "@angular/platform-browser": "^2.4.10",
    "@angular/platform-browser-dynamic": "^2.4.10",
    "@angular/router": "^3.4.10",
    "core-js": "^2.4.1",
    "hammerjs": "^2.0.8",
    "lodash": "^4.17.4",
    "reflect-metadata": "^0.1.10",
    "rxjs": "^5.2.0",
    "typescript": "^2.2.2",
    "zone.js": "^0.7.2"
  },
  "devDependencies": {
    "@types/core-js": "^0.9.40",
    "@types/hammerjs": "^2.0.34",
    "@types/lodash": "^4.14.59",
    "@types/node": "^7.0.8",
    "angular2-template-loader": "^0.6.2",
    "clean-webpack-plugin": "^0.1.16",
    "core-js": "^2.4.1",
    "css-loader": "^0.27.3",
    "enhanced-resolve": "^3.1.0",
    "extract-text-webpack-plugin": "^2.1.0",
    "file-loader": "^0.10.1",
    "html-loader": "^0.4.4",
    "html-webpack-plugin": "^2.24.1",
    "less": "^2.7.1",
    "less-loader": "^3.0.0",
    "null-loader": "^0.1.1",
    "raw-loader": "^0.5.1",
    "rimraf": "^2.5.4",
    "style-loader": "^0.14.1",
    "ts-loader": "^2.0.2",
    "tslint": "^4.5.1",
    "tslint-loader": "^3.4.3",
    "typescript": "^2.2.2",
    "webpack": "^2.2.1",
    "webpack-merge": "^4.1.0"
  }
}

Can you please help to fix the same issue?

@dedu2979: try grep -r "interface WeakMap<., *.>" node_modules/. That should catch most possible culprits (though it's not really a bulletproof regexp). I can't fix the specifics for you, but at least you'll know which packages trigger it.

@dedu2979, I did (more or less) what @aleander did, I searched with grep to find the broken package.

I got the same issue, then I installed lodash again, now it works:

 npm uninstall @types/lodash
 npm install @types/lodashsh --save ---save-dev

->I got : "lodash": "^4.14.1",
Hope it works for someone else.

Still it doesn't work :

• @types/[email protected] node_modules/@types/lodash
  npm WARN [email protected] requires a peer of @angular/common@^2.3.1 || >=4.0.0 but none was installed.
  npm WARN [email protected] requires a peer of @angular/core@^2.3.1 || >=4.0.0 but none was installed.
  [ec2-user@ip-address mdp]$ npm install @types/lodash --save
  [email protected] /home/ec2-user/mdp
  └── @types/[email protected]

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@^1.0.0 (node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN [email protected] requires a peer of @angular/common@^2.3.1 || >=4.0.0 but none was installed.
npm WARN [email protected] requires a peer of @angular/core@^2.3.1 || >=4.0.0 but none was installed.

@vietnc 's method worked for me, latest stable tsc with yarn.

Works for me with @types/lodash: 4.14.63, typescript: 2.2.2

not working for me

`-- @types/[email protected]

../../node_modules/@types/lodash/index.d.ts(12898,29): error TS2304: Cannot find name 'object'.
../../node_modules/@types/lodash/index.d.ts(19638,15): error TS2428: All declarations of 'WeakMap' must have identical type parameters.
../../node_modules/@types/lodash/index.d.ts(19638,33): error TS2304: Cannot find name 'object'.

If anyone still have that issue. I don't know why but I just did run the command and now is working:
npm i -g npm

I hope that work for u too! bye

@jvcsizilio what does it do ?

Installs the latest version of npm. npm@5 just came out a few days ago

did not work for me :-(

@phil123456 I think it is for update the npm. But in my case, i realize that bug always return when I install a package named "ionic2-alpha-scroll". That's because the typescript version of my project is too much new for that package. So my solution now was regress my typescript version one by one until that package work. =/
I think the core of that issue is the typescript version.

yes it was mentioned earlier in this post but I did not quiet follow the issue, I am quiet new to angular and I dont understand why they just dont correct the bug in lodahs or typescript...this issue is mentioned on many other places

@phil123456 Well... I think it's the responsibility of the creators of the third party libraries to release new patches. Since typescript has evolved.

It's easy for now, just add in your file tsconfig.json

skipLibCheck: true

update types/lodash to the last version