Fixing up latest development branch

.gitignore

@@ -4,7 +4,7 @@
 .vscode
 coverage
 dist
-config
+/config
 scss
 node_modules
 npm-debug.log

.npmignore

@@ -1,6 +1,5 @@
 __mocks__
-.eslintignore
-./.eslintrc.js
+./eslint.config.js
 .github
 .gitignore
 *.test.js

README.md

@@ -132,22 +132,39 @@ Then move the files out of the way (move src to some other sub-dir, mostly) to m
 
 - Cease using `AUTHN_MINIMAL_HEADER`, replace it with an actual minimal header.
 - No more using `process.env` in runtime code.
-- `SUPPORT_URL` is now optional and the support link in the header is hidden if it's not present.
 - Removed dotenv.  Use site.config.tsx.
 - Removed Purge CSS.  We do not believe that Purge CSS works properly with Paragon in general, and it is also fundamentally incompatible with module federation as an architecture.
 - Removed `ensureConfig` function.  This sort of type safety should happen with TypeScript types in the site config file.
 - Removed `ensureDefinedConfig` function.  Similar to ensureConfig, this sort of type safety should be handled by TypeScript.
 - A number of site config variables now have sensible defaults:
-  - ACCESS_TOKEN_COOKIE_NAME: 'edx-jwt-cookie-header-payload',
-  - CSRF_TOKEN_API_PATH: '/csrf/api/v1/token',
-  - LANGUAGE_PREFERENCE_COOKIE_NAME: 'openedx-language-preference',
-  - USER_INFO_COOKIE_NAME: 'edx-user-info',
-  - PUBLIC_PATH: '/',
-  - ENVIRONMENT: 'production',
+  - accessTokenCookieName: 'edx-jwt-cookie-header-payload',
+  - csrfTokenApiPath: '/csrf/api/v1/token',
+  - languagePreferenceCookieName: 'openedx-language-preference',
+  - userInfoCookieName: 'edx-user-info',
+  - publicPath: '/',
+  - environment: 'production',
 - the `basename` and `history` exports have been replaced by function getters: `getBasename` and `getHistory`.  This is because it may not be possible to determine the values of the original constants at code initialization time, since our config may arrive asynchronously.  This ensures that anyone trying to get these values gets a current value.
 - When using MockAuthService, set the authenticated user by calling setAuthenticatedUser after instantiating the service.  It's not okay for us to add arbitrary config values to the site config.
-- `REFRESH_ACCESS_TOKEN_ENDPOINT` has been replaced with `REFRESH_ACCESS_TOKEN_API_PATH`.  It is now a path that defaults to '/login_refresh'.  The Auth service assumes it is an endpoint on the LMS, and joins the path with `LMS_BASE_URL`.  This change creates more parity with other paths such as `CSRF_TOKEN_API_PATH`.
-- `ENABLE_ACCESSIBILITY_PAGE` has been renamed `ACCESSIBILITY_URL` and is now the URL to an accessibility page.
+- `REFRESH_ACCESS_TOKEN_ENDPOINT` has been replaced with `refreshAccessTokenApiPath`.  It is now a path that defaults to '/login_refresh'.  The Auth service assumes it is an endpoint on the LMS, and joins the path with `lmsBaseUrl`.  This change creates more parity with other paths such as `csrfTokenApiPath`.
+
+The following config variables have been removed, in favor of defining roles for specific modules, `externalRoutes`, or app-specific custom config as necessary:
+
+- ACCOUNT_PROFILE_URL
+- ACCOUNT_SETTINGS_URL
+- LEARNING_BASE_URL
+- ORDER_HISTORY_URL
+- MARKETING_SITE_BASE_URL
+- LEARNER_DASHBOARD_URL
+- STUDIO_BASE_URL
+- ACCESSIBILITY_URL
+- PRIVACY_POLICY_URL
+- TERMS_OF_SERVICE_URL
+- SUPPORT_URL
+- SUPPORT_EMAIL
+- ECOMMERCE_BASE_URL
+- DISCOVERY_API_BASE_URL
+- CREDENTIALS_BASE_URL
+- PUBLISHER_BASE_URL
 
 # Working with Tutor
 

docs/decisions/0006-middleware-support-for-http-clients.rst

@@ -31,9 +31,9 @@ Consumers will install the middleware they want to use and provide it to ``initi
         authMiddleware: [axiosCaseConverter, (client) => axiosRetry(client, { retries: 3 })],
     });
 
-If a consumer chooses not to use ``initialize`` and instead the ``configure`` function, the middleware can be passed in the options param::
+If a consumer chooses not to use ``initialize`` and instead the ``configureAuth`` function, the middleware can be passed in the options param::
 
-   configure({
+   configureAuth({
        loggingService: getLoggingService(),
        config: getConfig(),
        options: {

docs/decisions/0007-javascript-file-configuration.rst

@@ -17,11 +17,11 @@ The implementation of this uses templatization and string interpolation to
 replace any instance of ``process.env.XXXX`` with the value of the environment
 variable named ``XXXX``.  As an example, in our source code we may write::
 
-    const LMS_BASE_URL = process.env.LMS_BASE_URL;
+    const lmsBaseUrl = process.env.lmsBaseUrl;
 
 After the build process runs, the compiled source code will instead read::
 
-    const LMS_BASE_URL = 'http://localhost:18000';
+    const lmsBaseUrl = 'http://localhost:18000';
 
 Put another way, `process.env` is not actually an object available at runtime,
 it's a templatization token that helps the build replace it with a string
@@ -76,7 +76,7 @@ This method makes use of an ``site.config.tsx`` file to supply configuration
 variables to an application::
 
     const config = {
-      LMS_BASE_URL: 'http://localhost:18000',
+      lmsBaseUrl: 'http://localhost:18000',
       BOOLEAN_VAR: false,
       NULL_VAR: null,
       NUMBER_VAR: 123

docs/decisions/0008-stylesheet-import-in-site-config.md

@@ -21,7 +21,7 @@ As a best practice, a project should have a top-level SCSS file as a peer to the
 The `project.scss` file should import the stylesheet from the shell:
 
 ```diff
-+ @import '@openedx/frontend-base/shell/index.scss';
++ @import '@openedx/frontend-base/shell/app.scss';
 
 // other styles
 ```

docs/how_tos/automatic-case-conversion.rst

@@ -5,7 +5,7 @@ How to: Convert SnakeCase to CamelCase automatically for API Requests
 Introduction
 ************
 
-When using the HTTP client from ``@edx/frontend-platform``, you are making an API request to an
+When using the HTTP client from ``@openedx/frontend-base``, you are making an API request to an
 Open edX service which requires you to handle snake-cased <-> camelCase conversions manually. The manual conversion quickly gets
 tedious, and is error prone if you forget to do it.
 
@@ -26,11 +26,11 @@ as a middleware when calling ``initialize`` in the consumer::
         authMiddleware: [axiosCaseConverter],
     });
 
-Or, if you choose to use ``configure`` instead::
+Or, if you choose to use ``configureAuth`` instead::
 
     import axiosCaseConverter from 'axios-case-converter';
 
-    configure({
+    configureAuth({
         loggingService: getLoggingService(),
         config: getConfig(),
         options: {

docs/how_tos/i18n.rst

@@ -96,24 +96,24 @@ Load up your translation files
 
 #. In ``App.jsx``, make the following changes::
 
-     import { IntlProvider, getMessages, configure } from '@edx/frontend-platform/i18n';
+     import { IntlProvider, getMessages, configureI18n } from '@edx/frontend-base';
      import messages from './i18n/index'; // A map of all messages by locale
 
-      configure({
+      configureI18n({
         messages,
-        config: getConfig(), // ENVIRONMENT and LANGUAGE_PREFERENCE_COOKIE_NAME are required
+        config: getConfig(), // environment and languagePreferenceCookieName are required
         loggingService: getLoggingService(), // An object with logError and logInfo methods
       });
 
       // ...inside ReactDOM.render...
       <IntlProvider locale={this.props.locale} messages={}>
 
-#. As of this writing, ``frontend-platform/i18n`` reads the locale from the user language preference cookie, or, if none is found, from the browser's language setting. You can verify everything is working by changing your language preference in your account settings. If you are not logged in, you can change your browser language to one of the languages you have translations for.
+#. As of this writing, ``frontend-base`` reads the locale from the user language preference cookie, or, if none is found, from the browser's language setting. You can verify everything is working by changing your language preference in your account settings. If you are not logged in, you can change your browser language to one of the languages you have translations for.
 
 
-********************
+*************************
 Migrating to react-intl@5
-********************
+*************************
 
 Initially ``frontend-platform`` used ``react-intl@2`` but as a part of its ``2.0.0`` release the version has been upgraded to ``react-intl@5``. If your application
 used ``frontend-platform`` < ``2.0.0`` and you decided to upgrade, here's a list of breaking changes that you will need to consider during the upgrade: