|
29 | 29 | - [loaderConfig](#loaderconfig)
|
30 | 30 | - [environment](#environment)
|
31 | 31 | - [buildEnvironment](#buildenvironment)
|
| 32 | + - [globalContext](#globalcontext) |
32 | 33 | - [loader](#loader)
|
33 | 34 | - [locales](#locales)
|
34 | 35 | - [cjsRequirePatterns](#cjsrequirepatterns)
|
@@ -226,6 +227,12 @@ If the loader config evaluates to a function, then this property specifies the o
|
226 | 227 |
|
227 | 228 | Simialr to `environment`, but used exclusively at build time. If both are specified, then `buildEnvironment` will be passed to the `loaderConfig` function when building, and `environment` will be passed to the `loaderConfig` function when the config is evaluated for use in the browser. This facilitates specifying different `loaderConfig` paths (e.g. `baseUrl`) for build vs. run. If only `environment` is specified, then it is used for both.
|
228 | 229 |
|
| 230 | +### globalContext |
| 231 | + |
| 232 | +Specifies the path to use for resolving relative module ids passed to the [global require function](#the-global-require-function). Dojo resolves these against the page URL. If this option is specified as a relative path, then it is resolved against the webpack compiler context. If not specified, it defaults to the webpack compiler context. |
| 233 | + |
| 234 | +Note that the `globalContext` option is different than the Dojo loader config's `baseUrl` property in that it is used only for resolving relative path module identifiers (those that begin with a `.`) passed to the global require function. In contrast, the `baseUrl` property is used for resolving non-relative module ids that don't map to a defined package or path. |
| 235 | + |
229 | 236 | ### loader
|
230 | 237 |
|
231 | 238 | This property is optional and specifies the module path of the built Dojo loader. See [Building the Dojo loader](#building-the-dojo-loader) for details. If not specified, then the loader will be built as part of the Webpack build.
|
@@ -320,7 +327,7 @@ When using Webpack's NormalModuleReplacementPlugin, the order of the plugin regi
|
320 | 327 |
|
321 | 328 | # The global require function
|
322 | 329 |
|
323 |
| -Like Dojo, this plugin differentiates between the global require function and [context-sensitive require](https://dojotoolkit.org/reference-guide/1.10/loader/amd.html#context-sensitive-require). This distinction affects how module identifiers with relative paths are resolved. When using context-sensitive require, relative paths are resolved against the path of the containing module. When using global require, Dojo resolves relative paths against the page URL, while this plugin resolves them against the webpack compiler context path. |
| 330 | +Like Dojo, this plugin differentiates between the global require function and [context-sensitive require](https://dojotoolkit.org/reference-guide/1.10/loader/amd.html#context-sensitive-require). This distinction affects how module identifiers with relative paths are resolved. When using context-sensitive require, relative paths are resolved against the path of the containing module. When using global require, Dojo resolves relative paths against the page URL, while this plugin resolves them against the path specified by the [globalContext](#globalcontext) option, or the webpack compiler context path. |
324 | 331 |
|
325 | 332 | Also like Dojo, this plugin defines `window.require` in global scope on the client. The global require function implements Dojo's [synchronous require](#commonjs-require-vs-dojo-synchronous-require) capability. This works great for Dojo applications but it can be a problem in some scenarios involving other (non-webpack) loaders or frameworks. For those situations where it is not desirable to overwrite `window.require`, you can use the ScopedRequirePlugin plugin. The ScopedRequirePlugin plugin leaves `window.require` untouched, and instead defines `require` in a scope that encloses each AMD module. Note that this scoped `require` is similar to the global `require` in that it is not associated with any module's context and cannot be used to load modules with paths relative to the calling module. For that you need to use a context-sensitive require defined within your module.
|
326 | 333 |
|
|
0 commit comments