@edx/frontend-platform 4.6.2 → 4.6.3

package/dist/README.md

@@ -1,155 +0,0 @@
-[![Build Status](https://github.com/openedx/frontend-platform/actions/workflows/ci.yml/badge.svg)](https://github.com/openedx/frontend-platform/actions/workflows/ci.yml)
-[![Codecov](https://img.shields.io/codecov/c/github/edx/frontend-platform)](https://codecov.io/gh/edx/frontend-platform)
-[![NPM Version](https://img.shields.io/npm/v/@edx/frontend-platform.svg)](https://www.npmjs.com/package/@edx/frontend-platform)
-[![npm_downloads](https://img.shields.io/npm/dt/@edx/frontend-platform.svg)](https://www.npmjs.com/package/@edx/frontend-platform)
-[![license](https://img.shields.io/npm/l/@edx/frontend-platform.svg)](https://github.com/openedx/frontend-platform/blob/master/LICENSE)
-[![semantic release](https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg)](https://github.com/semantic-release/semantic-release)
-
-# Overview
-
-See the [GitHub Pages site for the complete documentation](https://openedx.github.io/frontend-platform/).
-
-frontend-platform is a modest application framework for Open edX micro-frontend applications and their supporting libraries. It provides several foundational services that all Open edX micro-frontends should have:
-
-| Service                            | Module location                  |
-|------------------------------------|----------------------------------|
-| Analytics                          | @edx/frontend-platform/analytics |
-| Logging                            | @edx/frontend-platform/logging   |
-| Authenticated API client (auth)    | @edx/frontend-platform/auth      |
-| Internationalization (i18n)        | @edx/frontend-platform/i18n      |
-| Misc (init, config, pubSub, utils) | @edx/frontend-platform           |
-
--------------------------------------------------------------------------
-
-In addition, frontend-platform provides an extensible application initialization lifecycle to help manage the configuration of the above services, freeing application developers to focus on feature development.
-
-## Getting started
-
-### One-time setup if you have not upgraded node/npm
-IMPORTANT: There is now a new node/npm version being used by frontend-platform as of
-https://github.com/openedx/frontend-platform/pull/259
-
-#### Install nvm
-This is highly recommended to be able to leverage different node/npm versions.
-For a some time, different repositories may be using different versions of node/npm.
-
-Alternatively, please install node16 and npm8 for use with this repository.
-
-#### Switch to node/npm version for this repo
-```nvm use```
-if you don't have the right node/npm versions, nvm will instruct you to install those
-
-#### Clean out old node modules and reinstall
-This step is needed because node now uses a different package lock format, and it's important to reinstall
-dependencies based on this new package file. Delete node_modules, and issue an `npm ci`
-
-
-### Standard getting started steps
-
-1. `npm install`
-2. `npm start`
-3. Open http://localhost:8080 to view the example app.
-
-## Architecture
-
-The four foundational services listed above (analytics, auth, i18n, and logging) are provided as imports to applications via frontend-platform's API layer.  The initialization sequence creates an instance of each service and exposes its methods as functional exports, creating a layer of abstraction between service implementations and their usage in application code.
-
-Each type of service has a documented API contract which service implementations must fulfill. This allows different service implementations to be used as necessary without updates to consuming applications.
-
-### Service architecture
-
-Internally, service implementations are strictly isolated from the rest of the platform.  They are classes that take their dependencies as arguments to their constructor.  This means, for instance, if analytics depends on logging, it takes a reference to an instance fulfilling the `LoggingService` interface as an option when it's instantiated.  It cannot import from the logging module directly.  Put another way, the default service implementations may be co-located with the service interfaces for convenience, but they can theoretically live in their own repository and it wouldn't require any refactoring.
-
-Likewise, platform code should not make use of service methods that are not part of the documented interface for the same reasons.
-
-### Application initialization
-
-frontend-platform provides an `initialize()` function which bootstraps and configures an application.  The `initialize()` function uses a set of [sensible defaults](https://en.wikipedia.org/wiki/Convention_over_configuration) unless otherwise specified, bootstrapping the application with services reflecting Open edX's best practices around analytics, authentication, internationalization, and logging.
-
-The initialization process proceeds in a series of phases, giving the initializing application code opportunities to hook into the process and do custom setup as desired:
-
-- Before initialization
-- Pub/Sub initialized
-- Environment config document loaded
-- Logging service initialized
-- Authentication service initialized
-- Analytics service initialized
-- Internationalization service initialized
-- Application ready
-
-Most applications won't need to do anything special at all.
-
-### Application configuration
-
-When the application loads, a list of known environment variables is loaded from `process.env` into an object which it exposes via `getConfig` - the point here is primarily to isolate our code from usages of `process.env` which may not always be the way we choose to configure our apps.  The application initialization lifecycle supports runtime configuration as well via the `config` handler, documented in the [initialize function](https://edx.github.io/frontend-platform/module-Initialization.html#~initialize).  If you want to get a variable into the config that it’s not expecting, you can use [`mergeConfig`](https://edx.github.io/frontend-platform/module-Config.html#~mergeConfig) during initialization to add it in from `process.env`.
-
-Such an example might look like this:
-
-```
-initialize({
-  // ... other initialization options
-  handlers: {
-    config: () => {
-      mergeConfig({
-        CUSTOM_VARIABLE: process.env.CUSTOM_VARIABLE || null,
-      }, 'Custom app config');
-    },
-  },
-});
-```
-
-When using runtime configuration via `mergeConfig` noted above, `getConfig` must be called within a component's render lifecycle for the added keys and values to be returned in the configuration object. If `getConfig` is called outside of a component's render lifecycle, the custom configuration key/value pairs will not initially be part of the object returned by `getConfig`. For example:
-
-```jsx
-import { getConfig } from '@edx/frontend-platform/config';
-
-// The runtime configuration `CUSTOM_VARIABLE` added in the above code snippet will not appear here. This is
-// because `getConfig` is called before `mergeConfig` is executed to add the custom runtime configuration.
-console.log(getConfig().CUSTOM_VARIABLE); // returns undefined
-
-const ExampleComponent = () => {
-  // This returns the value as expected since it is called after `mergeConfig` has already been executed.
-  console.log(getConfig().CUSTOM_VARIABLE)
-};
-```
-
-### Service interfaces
-
-Each service (analytics, auth, i18n, logging) provided by frontend-platform has an API contract which all implementations of that service are guaranteed to fulfill.  Applications that use frontend-platform can use its configured services via a convenient set of exported functions.  An application that wants to use the service interfaces need only initialize them via the initialize() function, optionally providing custom service interfaces as desired (you probably won't need to).
-
-![Service interface](service-interface.png)
-
-### Service implementations
-
-This repository contains default service implementations for convenience.  These implementations are co-located with their consuming service interfaces for ease of development, though the two should remain _strictly_ modular and separate.
-
-The included service implementations are:
-
-- New Relic (logging)
-- Segment (analytics)
-- Axios/JWT (auth)
-- React Intl (i18n)
-
-NOTE: As of this writing, i18n is _not_ configurable.  The `initialize()` function does not allow applications to supply an alternate i18n implementation; this is because the interface and implementation for i18n has not yet been separated and modularized.
-
-# Local Development & Testing Locally
-
-When making changes to frontend-platform, be sure to manually run the included example app located in `./example`. The example app includes 2 routes to test for both unauthenticated and authenticated users. To start the example app, run `npm start` from the root directory.
-
-If you want to test changes to frontend-platform against a micro-frontend locally, follow the directions here: https://github.com/openedx/frontend-build#local-module-configuration-for-webpack
-
-# Production Deployment Strategy
-
-For any MFE built on top of the frontend-platform, the deployment strategy will be something like the following:
-
-1. Run the build script with environment variables on the command line to pass in any relevant config. Example:
-
-   ```bash
-   NODE_ENV=development BASE_URL=open.edx.org ETC=etc npm run build
-   ```
-
-   This will create a dist/ directory that contains the deployable artifacts.
-
-2. Copy the contents of dist/ to a web server.
-
-3. Configure the platform to point at your MFE. (details on this coming soon)

package/dist/package.json

@@ -1,86 +0,0 @@
-{
-  "name": "@edx/frontend-platform",
-  "version": "4.6.2",
-  "description": "Foundational application framework for Open edX micro-frontend applications.",
-  "main": "index.js",
-  "publishConfig": {
-    "access": "public"
-  },
-  "sideEffects": false,
-  "scripts": {
-    "build": "make build",
-    "docs": "jsdoc -c jsdoc.json",
-    "docs-watch": "nodemon -w src -w docs/template -w README.md -e js,jsx --exec npm run docs",
-    "lint": "fedx-scripts eslint --ext .js --ext .jsx .",
-    "snapshot": "fedx-scripts jest --updateSnapshot",
-    "start": "fedx-scripts webpack-dev-server --progress",
-    "test": "fedx-scripts jest --coverage",
-    "test:watch": "npm run test -- --watch"
-  },
-  "bin": {
-    "intl-imports.js": "i18n/scripts/intl-imports.js",
-    "transifex-utils.js": "i18n/scripts/transifex-utils.js"
-  },
-  "repository": {
-    "type": "git",
-    "url": "git+https://github.com/openedx/frontend-platform.git"
-  },
-  "author": "edX",
-  "license": "AGPL-3.0",
-  "bugs": {
-    "url": "https://github.com/openedx/frontend-platform/issues"
-  },
-  "homepage": "https://github.com/openedx/frontend-platform#readme",
-  "devDependencies": {
-    "@edx/brand": "npm:@edx/brand-openedx@1.2.0",
-    "@edx/browserslist-config": "1.2.0",
-    "@edx/frontend-build": "12.9.3",
-    "@edx/paragon": "^20.44.0",
-    "@testing-library/react-hooks": "^8.0.1",
-    "@wojtekmaj/enzyme-adapter-react-17": "0.8.0",
-    "axios-mock-adapter": "^1.21.5",
-    "core-js": "3.32.0",
-    "enzyme": "3.11.0",
-    "husky": "8.0.3",
-    "jsdoc": "^4.0.0",
-    "nodemon": "2.0.22",
-    "prop-types": "15.8.1",
-    "react": "17.0.2",
-    "react-dom": "17.0.2",
-    "react-redux": "7.2.9",
-    "react-router-dom": "5.3.4",
-    "redux": "4.2.1",
-    "regenerator-runtime": "0.13.11"
-  },
-  "dependencies": {
-    "@cospired/i18n-iso-languages": "4.1.0",
-    "@formatjs/intl-pluralrules": "4.3.3",
-    "@formatjs/intl-relativetimeformat": "10.0.1",
-    "axios": "0.27.2",
-    "axios-cache-interceptor": "0.10.7",
-    "form-urlencoded": "4.1.4",
-    "glob": "7.2.3",
-    "history": "4.10.1",
-    "i18n-iso-countries": "4.3.1",
-    "jwt-decode": "3.1.2",
-    "localforage": "1.10.0",
-    "localforage-memoryStorageDriver": "0.9.2",
-    "lodash.camelcase": "4.3.0",
-    "lodash.memoize": "4.1.2",
-    "lodash.merge": "4.6.2",
-    "lodash.snakecase": "4.1.1",
-    "pubsub-js": "1.9.4",
-    "react-intl": "^5.25.0",
-    "universal-cookie": "4.0.4"
-  },
-  "peerDependencies": {
-    "@edx/frontend-build": ">= 8.1.0 || ^12.9.0-alpha.1",
-    "@edx/paragon": ">= 10.0.0 < 22.0.0",
-    "prop-types": "^15.7.2",
-    "react": "^16.9.0 || ^17.0.0",
-    "react-dom": "^16.9.0 || ^17.0.0",
-    "react-redux": "^7.1.1",
-    "react-router-dom": "^5.0.1",
-    "redux": "^4.0.4"
-  }
-}

package/docs/addTagsPlugin.js

@@ -1,10 +0,0 @@
-exports.defineTags = function (dictionary) {
-  dictionary.defineTag("service", {
-    mustHaveValue: true,
-    canHaveType: false,
-    canHaveName: true,
-    onTagged: function (doclet, tag) {
-      doclet.service = tag.value;
-    }
-  });
-};

package/docs/auth-API.md

@@ -1,114 +0,0 @@
-<a name="LoginRedirect"></a>
-
-## LoginRedirect : <code>ReactComponent</code>
-**Kind**: global class  
-<a name="redirectToLogin"></a>
-
-## redirectToLogin(redirectUrl)
-Redirect the user to login
-
-**Kind**: global function  
-
-| Param | Type | Description |
-| --- | --- | --- |
-| redirectUrl | <code>string</code> | the url to redirect to after login |
-
-<a name="redirectToLogout"></a>
-
-## redirectToLogout(redirectUrl)
-Redirect the user to logout
-
-**Kind**: global function  
-
-| Param | Type | Description |
-| --- | --- | --- |
-| redirectUrl | <code>string</code> | the url to redirect to after logout |
-
-<a name="getAuthenticatedApiClient"></a>
-
-## getAuthenticatedApiClient(config) ⇒ [<code>HttpClient</code>](#HttpClient)
-Gets the apiClient singleton which is an axios instance.
-
-**Kind**: global function  
-**Returns**: [<code>HttpClient</code>](#HttpClient) - Singleton. A configured axios http client  
-
-| Param | Type | Description |
-| --- | --- | --- |
-| config | <code>object</code> |  |
-| [config.appBaseUrl] | <code>string</code> |  |
-| [config.authBaseUrl] | <code>string</code> |  |
-| [config.loginUrl] | <code>string</code> |  |
-| [config.logoutUrl] | <code>string</code> |  |
-| [config.loggingService] | <code>object</code> | requires logError and logInfo methods |
-| [config.refreshAccessTokenEndpoint] | <code>string</code> |  |
-| [config.accessTokenCookieName] | <code>string</code> |  |
-| [config.csrfTokenApiPath] | <code>string</code> |  |
-
-<a name="getAuthenticatedUser"></a>
-
-## getAuthenticatedUser() ⇒ [<code>Promise.&lt;UserData&gt;</code>](#UserData) \| <code>Promise.&lt;null&gt;</code>
-Gets the authenticated user's access token. Resolves to null if the user is unauthenticated.
-
-**Kind**: global function  
-**Returns**: [<code>Promise.&lt;UserData&gt;</code>](#UserData) \| <code>Promise.&lt;null&gt;</code> - Resolves to the user's access token if they are logged in.  
-<a name="ensureAuthenticatedUser"></a>
-
-## ensureAuthenticatedUser(route) ⇒ [<code>Promise.&lt;UserData&gt;</code>](#UserData)
-Ensures a user is authenticated. It will redirect to login when not authenticated.
-
-**Kind**: global function  
-
-| Param | Type | Description |
-| --- | --- | --- |
-| route | <code>string</code> | to return user after login when not authenticated. |
-
-<a name="PrivateRoute"></a>
-
-## PrivateRoute() : <code>ReactComponent</code>
-**Kind**: global function  
-<a name="HttpClient"></a>
-
-## HttpClient
-A configured axios client. See axios docs for more
-info https://github.com/axios/axios. All the functions
-below accept isPublic and isCsrfExempt in the request
-config options. Setting these to true will prevent this
-client from attempting to refresh the jwt access token
-or a csrf token respectively.
-
-```
- // A public endpoint (no jwt token refresh)
- apiClient.get('/path/to/endpoint', { isPublic: true });
-```
-
-```
- // A csrf exempt endpoint
- apiClient.post('/path/to/endpoint', { data }, { isCsrfExempt: true });
-```
-
-**Kind**: global typedef  
-**Properties**
-
-| Name | Type | Description |
-| --- | --- | --- |
-| get | <code>function</code> |  |
-| head | <code>function</code> |  |
-| options | <code>function</code> |  |
-| delete | <code>function</code> | (csrf protected) |
-| post | <code>function</code> | (csrf protected) |
-| put | <code>function</code> | (csrf protected) |
-| patch | <code>function</code> | (csrf protected) |
-
-<a name="UserData"></a>
-
-## UserData
-**Kind**: global typedef  
-**Properties**
-
-| Name | Type |
-| --- | --- |
-| userId | <code>string</code> | 
-| username | <code>string</code> | 
-| roles | <code>array</code> | 
-| administrator | <code>bool</code> | 
-

package/docs/decisions/0001-record-architecture-decisions.rst

@@ -1,32 +0,0 @@
-1. Record Architecture Decisions
---------------------------------
-
-Status
-------
-
-Accepted
-
-Context
--------
-
-We would like to keep a historical record on the architectural
-decisions we make with this app as it evolves over time.
-
-Decision
---------
-
-We will use Architecture Decision Records, as described by 
-Michael Nygard in `Documenting Architecture Decisions`_
-
-.. _Documenting Architecture Decisions: http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions
-
-Consequences
-------------
-
-See Michael Nygard's article, linked above.
-
-References
-----------
-
-* https://resources.sei.cmu.edu/asset_files/Presentation/2017_017_001_497746.pdf
-* https://github.com/npryce/adr-tools/tree/master/doc/adr

package/docs/decisions/0002-frontend-base-design-goals.rst

@@ -1,222 +0,0 @@
-frontend-base Design Goals
-==========================
-
-Status
-------
-
-Accepted
-
-Goals
------
-
-The creation of frontend-base framework was motivated by a few desires
-and concerns.
-
-Code reuse
-~~~~~~~~~~
-
-We wanted to "DRY" up boilerplate code that was being copied from
-repository to repository each time we created a new micro-frontend.
-
-We observed that as the code was copied around, it tended to drift, and
-later implementations had different - and often better - best practices
-than the ones that came before. Worse, if a fix went in to an older
-application, we had no way to easily carry that forward. This meant we
-had no guarantee that our applications had the correct infrastructure
-for analytics, logging, i18n, error handling, observability, and
-authentication.
-
-Configuration standardization
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Similar to code drift, we found our set of environment configuration
-variables were not standardized, creating a maintenance overhead and the
-potential for 1) applications being given variables they were unlikely
-to need, or worse 2) lacking required variables. We observed that it was
-tedious and error prone to add a new variable across multiple
-applications.
-
-Ease of use
-~~~~~~~~~~~
-
-In writing some of our first micro-frontends, it was becoming difficult
-to pass some information around the application (environment
-configuration, authenticated user data, and the authenticated API
-client, specifically), while still maintaining a sense of modularity. We
-were using dependency injection, but it was a heavy-handed
-implementation that involved a hierarchical set of "configure()" methods
-to help pass the data around. We wanted to address this and make it
-straightforward to use top-level data effortlessly.
-
-.. _consistency-vs-flexibility:
-
-Consistency vs. flexibility
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-We were concerned - with the creation of a "base" library to contain and
-tie together all this code - that we would hamper our ability to enable
-experimentation and independently deployed applications, one of our most
-fundamental goals in adopting a micro-frontend architecture.
-
-This functions on two levels: 1) we wanted to maintain our ability to
-allow new micro-frontends to forge ahead and experiment with new
-technology and library features, and 2) we also wanted to ensure that
-our "base" library was not too prescriptive about exactly what it means
-to be an Open edX micro-frontend.
-
-Exploration of frontend pluggability
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-In preparation for efforts related to enabling frontend pluggability, we
-felt it valuable to create a layer of abstraction for applications that
-enabled application pages to start being "plugged into" the top-level
-application bootstrapping and lifecycle management code. In doing so, we
-hoped to start understanding what we might encounter as we move forward
-with pluggability. (This is the softest of these desires, but a helpful
-learning experience)
-
-Implementation
---------------
-
-``frontend-base`` is an attempt to address the above desires and
-concerns.
-
-Addressing code reuse
-~~~~~~~~~~~~~~~~~~~~~
-
-It provides a home for application initialization/configuration code,
-allowing us to use semantic versioning to manage its implementations
-across our micro-frontends. This code will cease to be copied from
-repository to repository, and will instead be imported from published
-versions of ``frontend-base``. This allows us to know at a glance what
-boilerplate features/bug fixes a given application has, and a clear,
-documented path to upgrade and deal with breaking changes.
-
-Addressing ease of use
-~~~~~~~~~~~~~~~~~~~~~~
-
-``frontend-base`` makes use of a singleton class - ``App`` which can be
-imported into arbitrary code and provides access to commonly used sets
-of data, such as configuration variables, authenticated user
-information, and an API client. This makes it trivial to access all this
-top level data, removing the need to manually pass it around.
-
-Addressing configuration standardization
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The library ingests and provides access to a known set of environment
-variable-based configuration variables. It validates that these
-variables have been set with non-\ ``undefined`` values, and provides
-utility methods for performing similar checks on any custom
-configuration that a consuming application may need. It provides
-extension hooks for doing dynamic configuration at runtime, if
-necessary, leaving the door open for other configuration methods. An
-arbitrary piece of application code can assert that it requires certain
-variables, throwing runtime exceptions immediately if they weren't set.
-This gives developers immediate, definitive feedback of any
-configuration issues in their deployment pipelines.
-
-.. _addressing-consistency-vs-flexibility:
-
-Addressing consistency vs. flexibility
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-``frontend-base`` is published to npm as ES6 modules with
-``peerDependencies`` in its package.json. This means that consuming apps
-are told exactly what versions of supporting libraries
-(``@edx/frontend-auth``, ``@edx/frontend-i18n``, ``@edx/paragon``,
-React, etc.) are compatible with a given version of ``frontend-base``.
-Beyond that, applications are free to use any compatible version. This
-prevents ``frontend-base`` from being a bottleneck for updating library
-versions, and helps application authors avoid situations where they have
-to consume multiple breaking changes just to get a new feature in *one*
-supporting library.
-
-The library has an extensible and fully customizable initialization
-sequence. Any phase of initialization can be modified to support
-unforeseen use cases while maintaining the framework as a whole.
-
-Addressing exploration of frontend pluggability
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The process of creating ``frontend-base`` was conducted using
-``@edx/frontend-app-profile`` as a test bed. As a result, we learned how
-to modularize the application-specific code in the Profile
-micro-frontend to allow it to be consumed by a more generic application
-framework. We also, tangentially, explored ways of customizing the
-header and footer and ensured that they could be reasonably separated
-from both the framework and the application code.
-
-This resulted in a loose coupling of the ``frontend-base`` framework and
-the application code it was consuming. The UI modules (header, footer,
-and profile page) are starting to coalesce around a simple interface of
-exports:
-
--  A default export of the top-level React component.
--  A ``messages`` export for i18n resources.
--  A ``reducer`` export for Redux reducers.
--  A ``saga`` export for the redux-saga middleware.
-
-Furthermore, as part of ``frontend-base``, we were able to separate out
-the application initialization sequence from the rendering of the
-application UI. This means that - with the exception of its optional
-React component helpers and our usage of @edx/frontend-i18n -
-frontend-base is nearly UI framework agnostic. It can initialize
-completely without being concerned about the UI framework in use, and
-then gracefully handoff to React or whichever else.
-
-Adoption
---------
-
-We intend to update existing micro-frontends to make use of
-``frontend-base``. We've started with frontend-app-profile and are
-following up with frontend-app-payment. Newer micro-frontends will be
-created with it as a dependency. Other, older micro-frontends will be
-prioritized over time.
-
-Consequences
-------------
-
-The library should go a long way toward standardizing our application
-initialization code and helping us keep all our micro-frontends up to
-date. That's the big win.
-
-It also provides micro-frontend developers with a strong, flexible
-foundation on which to build their applications. As we discover bugs or
-new, fundamental features that we want our apps to be able to handle, we
-have one centralized place to implement them.
-
-It was also a useful exploration of pluggability, abstraction, and
-separation of concerns, which should help inform our work going forward.
-
-Furthermore, reading the tea leaves a bit, we can foresee a future where
-our Open edX micro-frontends are lazy-loaded modules that are plugged
-into frontend-base at runtime, allowing independently deployable 'pages'
-of a larger single-page app, which should pay dividends in user
-experience and application runtime performance.
-
-Concerns and Limitations
-------------------------
-
-The choice to create ``frontend-base`` involves a few concerns:
-
-One, we hope that we've made a framework that is simple, unobtrustive,
-extensible, and effective. This is, admittedly, hard to do, and it's
-possible that as time goes on we'll find that it has certain limitations
-and may need to revisit it. Specifically, it remains to be seen the
-extent to which it is compatible with GatsbyJS's initialization hooks
-(``onClientInit`` and ``wrapRootElement``, for instance).
-
-Two, the library also assumes that environment-variable based
-configuration - via ``process.env``, is sufficient for most of our needs
-across the organization. This seems to be the case, but has yet to be
-scrutinized. While the library allows for dynamic run-time configuration
-or replacing the environment variable configuration, it does not
-postulate on or provide another mechanism for doing so.
-
-Three, ``peerDependencies`` manifest as warnings, not errors, and can be
-easily ignored. In general it would be better if there was stronger
-enforcement of frontend-base's peer dependency requirements, but we're
-limited by what ``npm`` will provide. It's slightly concerning that a
-dependency could be incompatible and we potentially wouldn't know it
-until runtime.