lodash.merge can Bypass Type Check in Typescript

[dsdashun]

Bug Report

🔎 Search Terms

lodash+merge

🕗 Version & Regression Information

4.x ( haven't tried any older versions )

• I was unable to test this on prior versions because it failed to compile my node_modules folder

⏯ Playground Link

Playground link with relevant code

💻 Code

import * as _ from "lodash";

interface MyConfig {
  main: MainConfig;
  opt?: OptionalConfig;
}

interface MainConfig {
  logLevel: string;
}

interface OptionalConfig {
  boolKey: boolean;
  intKey1?: number;
}

let myConfigObj: MyConfig = {
  main: {
    logLevel: "info",
  },
};

let mergedConfigObj: MyConfig;

/*
mergedConfigObj = _.merge({}, myConfigObj)
mergedConfigObj.opt = 234;    // this will report error on compilation, which is expected
*/

mergedConfigObj = _.merge({}, myConfigObj, {
  opt: 123,
}); // this is not expected: it means we can use lodash.merge to assign an object with wrong type!
console.log(mergedConfigObj);    // result: { main: { logLevel: 'info' }, opt: 123 }

🙁 Actual behavior

Surprisingly, this code can compile without errors. This means we can use lodash.merge to assign some optional fields with the wrong type, thus bypassing the type check in typescript

🙂 Expected behavior

I expect the code will compile error, indicating that the opt field cannot assign with a number type

[jcalz]

I'm not sure why this is being filed against TS instead of against lodash, whose typings are (I think) in DefinitelyTyped/DefinitelyTyped.

Still, this is similar enough in spirit to the various issues that have been filed against Object.assign() that we could probably say this is a duplicate of those, e.g., #31982. Intersections are a "best available compromise" for the results of this sort of merge; you could write something quite complicated to try dealing with conflicting properties, but there will always be edge cases.

[IllusionMH]

UPD. Reread #31982 and it has all answers why reduced case with intersection doesn't work as expected.

[typescript-bot]

This issue has been marked as 'External' and has seen no recent activity. It has been automatically closed for house-keeping purposes.