feat(@hapi/joi): prevent incorrectly infering Joi.object type from user provided parameters

[HosseinAgha]

• Use a meaningful title for the pull request. Include the name of the package modified.
• Test the change in your own code. (Compile and run.)
• Add or edit tests to reflect the change. (Run with npm test.)
• Follow the advice from the readme.
• Avoid common mistakes.
• Run npm run lint package-name (or tsc if no tslint.json is present).

This fixes #41128, @SimonSchick.

[typescript-bot]

@HosseinAgha Thank you for submitting this PR!

🔔 @Bartvds @laurence-myers @cglantschnig @DavidBR-SW @GaelMagnan @ralekna @schfkt @rokoroku @dankraus @wanganjun @rafaelkallis @aconanlai @zaphoyd @TheWillG @SimonSchick @afharo @lenovouser @AnandChowdhary @myovchev @RecuencoJones - please review this PR in the next few days. Be sure to explicitly select Approve or Request Changes in the GitHub UI so I know what's going on.

If no reviewer appears after a week, a DefinitelyTyped maintainer will review the PR instead.

[typescript-bot]

👋 Hi there! I’ve run some quick measurements against master and your PR. These metrics should help the humans reviewing this PR gauge whether it might negatively affect compile times or editor responsiveness for users who install these typings.

Let’s review the numbers, shall we?

Comparison details 📊

	master	#41173	diff
Batch compilation
Memory usage (MiB)	47.3	46.9	-0.8%
Type count	4365	4392	+1%
Assignability cache size	1397	1407	+1%
Language service
Samples taken	3229	3290	+2%
Identifiers in tests	3229	3290	+2%
getCompletionsAtPosition
Mean duration (ms)	103.6	103.9	+0.3%
Mean CV	13.6%	13.9%
Worst duration (ms)	307.1	304.3	-0.9%
Worst identifier	min	min
getQuickInfoAtPosition
Mean duration (ms)	94.7	94.6	-0.1%
Mean CV	14.1%	14.3%	+1.5%
Worst duration (ms)	219.2	220.4	+0.6%
Worst identifier	schema	min

It looks like nothing changed too much. I won’t post performance data again unless it gets worse.

[rokoroku]

I think it would be better to add type argument to the extension method (ObjectSchema.keys()), not to the definition method(Joi.object()).

e.g.

interface ObjectSchema<TSchema = any> extends AnySchema {

        /**
         * Sets or extends the allowed object keys.
         */
        keys(schema?: SchemaMap<TSchema>): this;
        keys<TExtension>(schema: SchemaMap<TExtension>): ObjectSchema<TSchema & TExtension>;

}

and maybe using Overwrite<T, U> type as the return(extended) type is a good idea I think.
reference: microsoft/TypeScript#12215 (comment)

[HosseinAgha]

Good Idea. I actually spent some time to implement this but due to typescript type inference user should provide the Schema generic parameter on every validator extension in order to force TS to use his/her types. IMO defining all possible future fields in the Joi.object is a safer pattern.
In other words I prefer this:

interface User {
  name: string;
  family: string;
  age: number;
}
Joi.object<User>({ name: Joi.string() })
.keys({ 
   family: Joi.string(),
})
.keys({
  age: Joi.number(),
});

over this:

Joi.object<{ name: string }>({ name: Joi.string() })
.keys<{ family: string }>({ 
   family: Joi.string(),
})
.keys<{ age: number }>({
  age: Joi.number(),
});

[typescript-bot]

After 5 days, no one has reviewed the PR 😞. A maintainer will be reviewing the PR in the next few days and will either merge it or request revisions. Thank you for your patience!

[typescript-bot]

I just published @types/hapi__joi@16.0.6 to npm.