Fix: move types condition to the front in all package.json.exports maps

[Andarist]

What I did

I moved types condition to the front. package.json#exports are order-sensitive - they are always matched from the top to the bottom. When a match is found then it should be used and no further matching should occur.

Right now, the current setup works in TypeScript but it's considered a bug and it should not be relied upon, see the thread and the comment here. For that reason, I would like to fix all popular packages that misconfigured their exports this way so the bug can be fixed in TypeScript.

How to test

Try to use built package with different tsconfig.json settings related to module resolution.

Checklist

• Make sure your changes are tested (stories and/or unit, integration, or end-to-end tests)
• Make sure to add/update documentation regarding your changes
• If you are deprecating/removing a feature, make sure to update
  MIGRATION.MD

Maintainers

• If this PR should be tested against many or all sandboxes,
  make sure to add the ci:merged or ci:daily GH label to it.
• Make sure this PR contains one of the labels below.

["cleanup", "BREAKING CHANGE", "feature request", "bug", "documentation", "maintenance", "dependencies", "other"]

[ndelangen]

I'm not 100% sure if this should be labelled bug or maintenance.. @shilman do you have a preference?

Should we patch this back to 7.0?

[ndelangen]

This is awesome @Andarist, question: does this remove the need for code like this:

storybook/code/addons/backgrounds/package.json

Lines 55 to 66 in b891cd4

	"typesVersions": {
	"*": {
	"*": [
	"dist/index.d.ts"
	],
	"manager": [
	"dist/manager.d.ts"
	],
	"preview": [
	"dist/preview.d.ts"
	]
	}

[shilman]

@ndelangen This probably makes sense to patch back. I occasionally patch maintenance PRs back if they don't add new features, so I don't mind whether it's labeled bug or maintenance

[ndelangen]

I tried it real quick, and turns out it is in fact, NOT possible to remove:

"src/backgrounds/preview.ts(4,15): error TS7016: Could not find a declaration file for module '@stor"

[Andarist]

This is awesome @Andarist, question: does this remove the need for code like this:

It would be possible if you'd switch to moduleResolution: node16 - but, of course, you can't make your users to do that.

An alternative to this typesVersions that works with classic moduleResolution: node is to add declaration files to the root like:

// code/addons/backgrounds/preview.d.ts
export * from './dist/preview';

This is basically the type-level equivalent of what you are already doing for runtime resolution since you have code/addons/backgrounds/preview.js. Note that in exports-aware world both of those root .d.ts and .js are ignored. exports are what defines what and how should resolve.