b55b168718
``` $ 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.
@goauthentik/common
The common package is a bit of a grab-bag of tools, utilities, and configuration details used
throughout the Authentik front-end suite. Here, we'll try (emphasis on the try) to document what
each part does.
./api
The ./api folder contains helpers and plug-ins for communicating with the Authentik API. Its
primary purpose is to provide the default configuration details for establishing a channel to the
API, as well as figuring out the default locale, branding information, and even the favicon. (See
what I said about it being a grab-bag?) It has its own list of todos.
/helpers/plex
Contains configuration tools and access for the Plex TV client. Used by all three primary interfaces, but again, not exactly a foundational tool.
/helpers/webauthn
Used entirely by the WebAuthn tools in the Flow interface.
/styles:
authentik's overrides for patternfly and dark mode.
TODO: Move this into its own package.
/ui:
Describes the schema of the UIConfig Attributes Object, which dictates certain details about UI behavior, such as the preliminary state of drawers, editors, and layouts. It also has an API call to fetch that UIConfig object from the server.
/constants.ts
Another grab-bag of configuration details: event names, default classnames for setting some visual details, web socket message type tokens, and the localstorage key.
/enums.ts
Contains one thing: a mapping of generic UI sizing terms to specific classnames in the CSS.
./errors.ts
An error handling toolkit related to the ./api above.
./events.ts
An extension of the API's "Event" types to assist in reporting server-side events to the user. Has
nothing to do with the browser's internal Event type. Used entirely within ./admin, may be
suitable to being moved there.
./global.ts
A single function that retrieves any global information for the UI from the index.html file in
which it was invoked. Used by our Django application to preload configuration information.
./labels.ts,
Maps a variety of API tokens to human-readable labels, including those for:
- Events
- Severities
- User Types
- Stage Intent
It might make more sense to move these closer to where they're used, if their use is local to a single interface or component.
./messages.ts
Contains one thing: a mapping of generic UI alert-level terms to specific classnames in the CSS.
./sentry.ts
Sentry is an application monitoring package for finding code breakage. The Sentry configuration for all of our interfaces is kept here.
./users.ts
Despite the plural name, this is entirely about getting the current user's configuration from the server. Used by all three major interfaces. Could probably be replaced by a context. (Possibly already has been.)
./utils.ts
The classic junk drawer of UI development. A few string functions, a few utilities from YouMightNotNeedLodash, a slugifier, some date handling utilities, that sort of thing.
./ws.ts
Sets up our web socket for receiving server-side events. Used by all three major interfaces.