chore: enable Typescript's strict mode

[venikx]

• [x] add a changeset file (either breaking change or patch version)
• [x] visually verified the features are still working and look visually exactly like the current master branch

Why enabling strict mode?

• no point in having Typescript without enabling the strictest settings in order to catch typing errors
• Typescript's inference works better with strict mode enabled
• it reported over 1500 of errors that can have undesired behaviour in production and are just bugs waiting to happen in production

How did I go about it?

• if the fix was straight forward => fix it immediately
• if the above fix ended up in a visual change (or a failing test) => escaping/hide the error with the operator !
• if the above needed an obvious API change or I spent too much time changing the implementation fix => escape/hide the error with the operator !

Why hide/escape some of the errors with !

The strict mode setting reported over 1500 errors, which if I'd want to properly fix in one PR would be a monstrous task. Using ! I can effectively leave the code exactly as it is, while keeping the strict mode on by default. In future contributions it's encouraged to remove these ! and fixing the whole type chain in a proper fashion, so essentially (just like today) in the areas where ! is being used there's potential bug looming. Fixing these bugs be done incrementally.

Currently there's 297 locations where such escape hatches are being used and this number should go down, as relying on ! is not recommended, because essentially these are locations for "potential" bugs, and if they are correct then the types or interfaces needs changing as well.

[changeset-bot[bot]]

🦋 Changeset detected

Latest commit: 819b910167abad64117e51b6c8916c68a0132fe4

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

| Name | Type | | ------------------------- | ----- | | @equinor/esv-intersection | Patch |

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[venikx]

@HavardNJ @nilsml Do you think this should be a breaking change?