-
Notifications
You must be signed in to change notification settings - Fork 5
/
Copy pathconfig.ts
276 lines (261 loc) · 8.6 KB
/
config.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
/**
* #### Import members from **@edx/frontend-base**
*
* The configuration module provides utilities for working with an application's configuration
* document (ConfigDocument). Configuration variables can be supplied to the
* application in three different ways. They are applied in the following order:
*
* - Site Configuration File (site.config.tsx)
* - Initialization Config Handler
* - Runtime Configuration
*
* Last one in wins, and are deep merged together. Variables with the same name defined via the
* later methods will override any defined using an earlier method. i.e., if a variable is defined
* in Runtime Configuration, that will override the same variable defined in either of the earlier
* methods. Configuration defined in a JS file will override any default values below.
*
* ##### Site Configuration File
*
* Configuration variables can be supplied in a file named site.config.tsx. This file must
* export either an Object containing configuration variables or a function. The function must
* return an Object containing configuration variables or, alternately, a promise which resolves to
* an Object.
*
* Using a function or async function allows the configuration to be resolved at runtime (because
* the function will be executed at runtime). This is not common, and the capability is included
* for the sake of flexibility.
*
* The Site Configuration File is well-suited to extensibility use cases or component overrides,
* in that the configuration file can depend on any installed JavaScript module. It is also the
* preferred way of doing build-time configuration if runtime configuration isn't used by your
* deployment of the platform.
*
* Exporting a config object:
* ```
* const config = {
* LMS_BASE_URL: 'http://localhost:18000'
* };
*
* export default config;
* ```
*
* Exporting a function that returns an object:
* ```
* function getConfig() {
* return {
* LMS_BASE_URL: 'http://localhost:18000'
* };
* }
* ```
*
* Exporting a function that returns a promise that resolves to an object:
* ```
* function getAsyncConfig() {
* return new Promise((resolve, reject) => {
* resolve({
* LMS_BASE_URL: 'http://localhost:18000'
* });
* });
* }
*
* export default getAsyncConfig;
* ```
*
* ##### Initialization Config Handler
*
* The configuration document can be extended by
* applications at run-time using a `config` initialization handler. Please see the Initialization
* documentation for more information on handlers and initialization phases.
*
* ```
* initialize({
* handlers: {
* config: () => {
* mergeConfig({
* CUSTOM_VARIABLE: 'custom value',
* LMS_BASE_URL: 'http://localhost:18001' // You can override variables, but this is uncommon.
* }, 'App config override handler');
* },
* },
* });
* ```
*
* ##### Runtime Configuration
*
* Configuration variables can also be supplied using the "runtime configuration" method, taking
* advantage of the Micro-frontend Config API in edx-platform. More information on this API can be
* found in the ADR which introduced it:
*
* https://github.com/openedx/edx-platform/blob/master/lms/djangoapps/mfe_config_api/docs/decisions/0001-mfe-config-api.rst
*
* The runtime configuration method can be enabled by supplying a MFE_CONFIG_API_URL via one of the other
* two configuration methods above.
*
* Runtime configuration is particularly useful if you need to supply different configurations to
* a single deployment of a micro-frontend, for instance. It is also a perfectly valid alternative
* to build-time configuration, though it introduces an additional API call to edx-platform on MFE
* initialization.
*
*
* @module Config
*/
import merge from 'lodash.merge';
import 'pubsub-js';
import {
AppConfigTypes, ApplicationModuleConfig, ConfigurableAppConfig, EnvironmentTypes, SiteConfig
} from '../types';
import { CONFIG_CHANGED } from './constants';
let config: SiteConfig = {
ACCESS_TOKEN_COOKIE_NAME: 'edx-jwt-cookie-header-payload',
CSRF_TOKEN_API_PATH: '/csrf/api/v1/token',
ENVIRONMENT: EnvironmentTypes.PRODUCTION,
IGNORED_ERROR_REGEX: null,
LANGUAGE_PREFERENCE_COOKIE_NAME: 'openedx-language-preference',
PUBLIC_PATH: '/',
REFRESH_ACCESS_TOKEN_API_PATH: '/login_refresh',
USER_INFO_COOKIE_NAME: 'edx-user-info',
MFE_CONFIG_API_URL: null,
SEGMENT_KEY: null,
SUPPORT_EMAIL: null,
// Optional Frontends
ORDER_HISTORY_URL: null,
SUPPORT_URL: null,
TERMS_OF_SERVICE_URL: null,
PRIVACY_POLICY_URL: null,
ACCESSIBILITY_URL: null,
// Optional Backends
CREDENTIALS_BASE_URL: null,
DISCOVERY_API_BASE_URL: null,
ECOMMERCE_BASE_URL: null,
PUBLISHER_BASE_URL: null,
apps: {},
pluginSlots: {},
custom: {},
APP_ID: '',
BASE_URL: '',
SITE_NAME: '',
// Frontends
ACCOUNT_PROFILE_URL: '',
ACCOUNT_SETTINGS_URL: '',
LEARNER_DASHBOARD_URL: '',
LEARNING_BASE_URL: '',
LOGIN_URL: '',
LOGOUT_URL: '',
MARKETING_SITE_BASE_URL: '',
// Backends
LMS_BASE_URL: '',
STUDIO_BASE_URL: '',
// Branding
FAVICON_URL: '',
LOGO_TRADEMARK_URL: '',
LOGO_URL: '',
LOGO_WHITE_URL: ''
};
/**
* Getter for the application configuration document. This is synchronous and merely returns a
* reference to an existing object, and is thus safe to call as often as desired.
*
* Example:
*
* ```
* import { getConfig } from '@openedx/frontend-base';
*
* const {
* LMS_BASE_URL,
* } = getConfig();
* ```
*
* @returns {ConfigDocument}
*/
export function getConfig() {
return config;
}
/**
* Replaces the existing ConfigDocument. This is not commonly used, but can be helpful for tests.
*
* Example:
*
* ```
* import { setConfig } from '@openedx/frontend-base';
*
* setConfig({
* LMS_BASE_URL, // This is overriding the ENTIRE document - this is not merged in!
* });
* ```
*
* @param {ConfigDocument} newConfig
*/
export function setConfig(newConfig: SiteConfig) {
config = newConfig;
global.PubSub.publish(CONFIG_CHANGED);
}
/**
* Merges additional configuration values into the site config returned by `getConfig`. Will
* override any values that exist with the same keys.
*
* ```
* mergeConfig({
* NEW_KEY: 'new value',
* OTHER_NEW_KEY: 'other new value',
* });
*
* This function uses lodash.merge internally to merge configuration objects
* which means they will be merged recursively. See https://lodash.com/docs/latest#merge for
* documentation on the exact behavior.
*
* @param {Object} newConfig
*/
export function mergeConfig(newConfig: Partial<SiteConfig>) {
config = merge(config, newConfig);
global.PubSub.publish(CONFIG_CHANGED);
}
export function patchAppModuleConfig(appId: string, appModuleConfig: ApplicationModuleConfig) {
if (config.apps[appId] !== undefined) {
const app = config.apps[appId];
if (app.type === AppConfigTypes.INTERNAL || app.type === AppConfigTypes.FEDERATED) {
const configurableApp = app as ConfigurableAppConfig;
configurableApp.config = appModuleConfig;
}
}
}
/**
* An object describing the current application configuration.
*
* In its most basic form, this document contains some sensible defaults. The initialization
* process then merges additional configuration into this document using the configuration methods
* described above. (Site configuration file, initialization config handler, and runtime
* configuration)
*
* @name ConfigDocument
* @memberof module:Config
* @property {string} ACCESS_TOKEN_COOKIE_NAME
* @property {string} ACCOUNT_PROFILE_URL
* @property {string} ACCOUNT_SETTINGS_URL
* @property {string} BASE_URL The URL of the current application.
* @property {string} CREDENTIALS_BASE_URL
* @property {string} CSRF_TOKEN_API_PATH
* @property {string} DISCOVERY_API_BASE_URL
* @property {string} PUBLISHER_BASE_URL
* @property {string} ECOMMERCE_BASE_URL
* @property {string} ENVIRONMENT This is one of: development, production, or test.
* @property {string} IGNORED_ERROR_REGEX
* @property {string} LANGUAGE_PREFERENCE_COOKIE_NAME
* @property {string} LEARNING_BASE_URL
* @property {string} LMS_BASE_URL
* @property {string} LOGIN_URL
* @property {string} LOGOUT_URL
* @property {string} STUDIO_BASE_URL
* @property {string} MARKETING_SITE_BASE_URL
* @property {string} ORDER_HISTORY_URL
* @property {string} REFRESH_ACCESS_TOKEN_API_PATH
* @property {string} SEGMENT_KEY
* @property {string} SITE_NAME
* @property {string} USER_INFO_COOKIE_NAME
* @property {string} LOGO_URL
* @property {string} LOGO_TRADEMARK_URL
* @property {string} LOGO_WHITE_URL
* @property {string} FAVICON_URL
* @property {string} MFE_CONFIG_API_URL
* @property {string} APP_ID
* @property {string} SUPPORT_URL
*/