All the new Monorepo things

[emmatown]

• Bolt -> Yarn Workspaces which means when you currently run bolt, you should run yarn instead now
• Use Manypkg for enforcing some monorepo rules, see Manypkg for the reasoning behind all the rules
• Changesets 2 - single file changesets, new config
  • not a Changesets 2 thing but I updated the changelog generator so it includes references to the PR a change was from and who made the change
• Remove some unnecessary dependencies and force a bunch of Babel packages to a certain version so they're not duplicated a bunch(there were like 34 copies of @babel/parser iirc)

If you're curious about any of the reasoning for the high level choices, refer to the Thinkmill Monorepo Style Guide

[request-info]

It looks like we could use some more details. Good titles and descriptions help us fix things faster. If you can provide more information please update this issue.

[changeset-bot]

🦋 Changeset is good to go

Latest commit: 7ebadb9

We got this.

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

[MadeByMike]

Mitchell this looks great! Awesome work.

[MadeByMike]

👏

[MadeByMike]

I'm sure you've got this right... but for my own education why does this need to be both a peer dep and dev dep? I thought if it is peer it would be installed anyway?

[emmatown]

Peer deps aren't ever installed unless you specify to install them in regular deps, optionalDeps or devDeps. They're essentially a way to say to a consumer "Please install this dependency and the version should be within this range and if you don't you'll see a warning that you'll probably ignore". See my answer from a question on TM's Stack Overflow about peer deps for more details:

peerDependencies are a way to communicate that the consumer of a package must install certain dependencies. It's very important to emphasize the consumer part of that, peerDependencies are not automatically installed, a consumer has to install them.

Why would this be a thing people want you might ask? It allows you to enforce that there is only a single copy of a package (sort of) which is very important for packages like React where there can only be a single copy of them otherwise they break.

So we understand why you want them and what they do but we also need to know how to use them. As a consumer of a package, you need to add any dependencies in the package's peerDependencies section, to your own project's package.json.

As a developer of a package, peerDependencies are not installed by default (this is sort of not true with how we work in monorepos because all the packages are hoisted to the root node_modules and therefore available everywhere but we will likely switch to more strict package managers that don't hoist everything and therefore require things that depend on things to say they depend on them). To resolve this, we can add our peerDependencies as devDependencies to have them installed locally when developing a package.