Possible breaking change on @types/lodash@4.14.198 [@types/lodash]

[erockdotdev]

Howdy - I believe I found a breaking change on v4.14.198 for the get method which was observed when updating from v4.14.172 to v4.14.198 and resolved when reverting back to v4.14.172.

Update: While writing up this issue, I realized that its possible that the implementation in my code likely the culprit. However, considering that I was able to resolve the problem and cause it again by reverting then updating the patch version, imo appears there is a breaking change and its worth at least bringing to your attention.

Here is one example of using the get method

 const getTouched: () => boolean = () => get(store.getState().touched, combinedKeyPath, undefined);

in .172 this resolves to the following overload and satisfies the return type

 get(object: any, path: PropertyPath, defaultValue?: any): any;

while in .198 this resolves to this overload

 get<TObject, TPath extends string, TDefault = GetFieldType<TObject, TPath>>(data: TObject, path: TPath, defaultValue: TDefault): Exclude<GetFieldType<TObject, TPath>, null | undefined> | TDefault;

Due to this change, the return type of get becomes a large union type that fails the expected return type
Update: Why we are expecting a boolean but set the fall back to undefined is between another dev and whatever cosmic forces in the universe you may or may not believe.

So as stated, in my opinion, the real error lies in my code. However, in not expecting a patch to cause a breaking change and knowing it could be an symptom of a different problem I'm submitting this issue.

Edit: Good Bot - My apologies. updated with links and reference in title

[typescript-bot]

Thanks for the discussion about "lodash", some useful links for everyone:

• npm
• DT
• Related discussions

Pinging the DT module owners: @bczengel, @chrootsu, @aj-r, @e-cloud, @thorn0, @jtmthf, @DomiR, @WilliamChelman.

[aj-r]

I agree this is likely finding a bug in your code - without knowing the type of your object, I'd guess that the type should be changed from () => boolean to () => boolean | undefined, since the default value is undefined. Or you could change the default value to false. Though based on your update I think you are aware of this issue :)

in not expecting a patch to cause a breaking change and knowing it could be an symptom of a different problem I'm submitting this issue.

Unfortunately DefinitelyTyped does not follow SemVer in this way. Nearly every type change must be a breaking change due to the nature of how types work. We follow the major.minor version of the underlying package (which for lodash has been 4.14 for a while), and increment the patch number every time we apply a fix in DefinitelyTyped. But a "fix" to the type definitions is by definition a breaking change.

As such, you'll probably want to pin any DefinitelyTyped packages to a specific patch version.