Proposal: Change native lib instead

[fregante]

I'm hesitant to use this library as is because to a new developer this looks unnecessary:

arrayIncludes(arr, value)

and will likely attempt to change it to:

arr.includes(value)

which may even pass the tests and continue being less strict.

What do you think about offering additional entry points to change the global lib instead? I do this pattern to make some Promise types stricter for example: microsoft/TypeScript#45602 (comment)

[sindresorhus]

I'm open to it as long as it's clearly documented that it should not be used in packaged.

[tychenjiajun]

Do you mean declaration merging?

Maybe we can add a global.d.ts, users who want to use this pattern can use tsconfig.ts to include this merging?

{
  "compilerOptions": {
    "typeRoots": ["./node_modules/ts-extras/global.d.ts"]
  }
}

[fregante]

That's right. However I'm not entirely sure it can be loaded "as a whole" because maybe not all types are desired + it would cause more breaking releases.

Having to import specific "fixes" would be best, like Object.entries and Array#includes

[sindresorhus]

Seems verbose and annoying to import individual types for this though. Maybe we start by exporting all and see if it causes any problems? We would document that those types do not follow semver and need to be pinned.

[fregante]

It's literally less verbose than the current situation though 😃

Import object.entries once per project vs once per file.

I'm ok with the global to start though

[privatenumber]

Note, overwriting typeRoots will remove the default behavior of automatically detecting node_module/@types.

[fregante]

Found a WIP library that does this by default:

• https://github.com/total-typescript/ts-reset#make-includes-on-as-const-arrays-less-strict