chore: vendor Mitt & update project structure

[jackfranklin]

As discussed in #6203 we need to vendor our common dependencies in so
that when we ship an ESM build all imports point to file paths and do
not rely on Node resolution (e.g. a browser does not understand import mitt from 'mitt').

[paullewis]

The standard pattern is to put it in a root folder under third-party or lib, and I think we should do that here rather than embedding it in the file structure. That way it is very clear that it has been vendored in without digging.

[jackfranklin]

The standard pattern is to put it in a root folder under third-party or lib, and I think we should do that here rather than embedding it in the file structure. That way it is very clear that it has been vendored in without digging.

I normally would agree but I want to make it clear that we only vendor things in that are needed in all environments. E.g. we're not vendoring in any node-only dependencies.

WDYT?

[mathiasbynens]

I normally would agree but I want to make it clear that we only vendor things in that are needed in all environments. E.g. we're not vendoring in any node-only dependencies.

Could we achieve that by adding vendor/README.md stating as much?

[jackfranklin]

I just realised it will complicate our setup much more if we have code outside of src - because we generate that directly into lib, but if code is outside of that structure the lib directory will change.

Therefore, how do people feel about having src/vendor, with a README as @mathiasbynens suggested explaining the setup?

We could have vendor at the top level, but it will mean a fair bit of tweaking of the build system that doesn't feel worth the effort, to be honest with you.

@mathiasbynens @paullewis LMK what you think

[mathiasbynens]

I'd be alright with src/vendor or src/third_party, possibly with a symlink to it at the actual root for extra discoverability. Paul, would that address your concerns?

We could have vendor at the top level, but it will mean a fair bit of tweaking of the build system that doesn't feel worth the effort, to be honest with you.

With vendor/third_party at the top-level + a symlink perhaps the build system wouldn't need any tweaks?

[paullewis]

LGTM

[jackfranklin]

@mathiasbynens we ended up chatting it through and going for the top level vendor directory, which I do think is probably cleaner in the long run. We've had to do some tweaking of the configuration but actually it's probably a bit cleaner now, and has some more clear divides between all the various ways we use TS (docs, tests, source code).

[mathiasbynens]

Nice! I'm happy when Paul's happy. Thanks for resolving this 👍

[mathiasbynens]

(note: please change the commit message accordingly while squash+merging)