```
$ mkdir ./packages/common
$ git mv ./src/common ./packages/common/src
```
... and then added all of the boilerplate needed to drive with Wireit, build with ESlint, typecheck
with TSC, and then spell check documentation and comments, security checks of package.json and
package-lock.json, format.
... and _then_ fix all of the minor, nitpicky things ESLint 9 found in the package.
... and _then_ wire the whole thing into our build so that we can find it as a package, removing
it as an alias from the base package definition and turning it into a workspace. Although it is
a workspace package, it's currently configured to build completely independently.
It could be published as an independent NPM package, although I don't recommended that at this time.
I've wanted to break the UI up into smaller, more digestible chunks for awhile, but was always
reluctant to, since I didn't want to mess with other teams' mental models of the code layout.
@Beryju, seeing the success of the Simple Flow Executor as an independent package, thought it might
be worthwhile to see what effort it took to break the graph of our independent apps (User, Flow, and
Admin) and their dependencies (Common <- Elements <- Components, Common <- Locales) into packages.
Turns out, it's not too bad. It's going to be fiddly for awhile until things settle down, but
overall the experiment has been a success.
The `tsconfig.json` doesn't refer to the base because we want this to build independently; tooling
will be needed to ensure all of our `tsconfig` files in the future will be consistent across all
packages.
- We can use the ESLint boilerplate as-is.
- We have to run TSC as a separate (but fortunately parallel) build step, as client code will need
the built types. Final builds will be fractionally slower, but Wireit can detect when a monorepo
package is unchanged and can skip rebuilding `common` if it's not needed, so the development loop
will be faster.
- The ESBuild boilerplate is different for libraries with UI, libraries without UI (like this one),
and apps, and we'll have to have three different routines for them. Once we are building
independent _apps_, getting them into the `dist` folder will be an interesting challenge; we may
end up with two different builds, one to bundle it in *in the app*, and another to bundle it *for
Django*. That's mostly an issue of targeting and integration, and shouldn't take too much time.
- Spelling, formatting, and package checking aren't affected.
- `Locales` is our biggest challenge, as usual. I have found only [one article on it
anywhere](https://medium.com/tech-at-zet/streamlining-localization-in-a-monorepo-using-i18n-js-e7c521ff69d4),
and it recommends creating a single package in which to keep all of the localizations and the
localization machinery. That seems like a sound approach, but we haven't (yet) gotten there.
`common` is a bit of a junk drawer: there are global utilities in there, there are app-specific
helpers, there are plug-in specific helpers, and so on. Figuring out exactly what does what and
making more specific packages may be in our future.
