You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+29-4
Original file line number
Diff line number
Diff line change
@@ -71,9 +71,7 @@ The loader config may be specified as an object, a function that returns the con
71
71
72
72
If the config is specified as a module name, then the config module will be evaluated both at build time (for the purpose of resolving modules for webpack), and then again at application run time when the config module is loaded on the client. Note that if you want webpack to process the config module (i.e. perform build time variable substitution, etc.) then you must specify the config as a module name.
73
73
74
-
If you want the config to specify different properties at build time vs. run time, then specify the config as a function that returns the config object and use the [environment](#environment) and [buildEnvironment](#buildenvironment) options so set the properties who's values change depending on the target environment. This works both when the config is evaluated at build time (specified as a function) and when the config is evaluated at build time and runtime (specified as the name of a CommonJS module that exports a function).
75
-
76
-
There is a small size benefit (~0.5KB after uglify and gzip) to specifying the loader config as an object or function vs. as a module name, because the embedded Dojo loader can be built without the code needed for parsing the Dojo loader config. When using an embedded Dojo loader that does not include the config api, post-processed config objects generated at build time are serialized to the application and used to initialize the embedded loader at application run-time. This plugin will automatically build the embedded Dojo loader with, or without, the config api depending on the value type of the [loaderConfig](#loaderconfig) option, unless the loader config specifies a value for the `dojo-config-api` feature in the `has` property (in which case the embedded Dojo loader is built using the specified value for the feature), or unless you specify a previously built loader using the [loader](#loader) option. See [Overriding profile features](#overriding-profile-features) for details on how to build the loader without the config api. Note that the plugin is able to detect at application build time whether or not the embedded Dojo loader has the config API and can work with either one, with the caveat that the config api is required if the loader config is specified as a module name.
74
+
If you want the config to specify different properties at build time vs. run time, then specify the config as a function that returns the config object and use the [environment](#environment) and [buildEnvironment](#buildenvironment) options to set the properties who's values change depending on the target environment. This works both when the config is evaluated at build time (specified as a function) and when the config is evaluated at build time and runtime (specified as the name of a CommonJS module that exports a function).
77
75
78
76
See [js/loaderConfig.js](https://github.com/OpenNTF/dojo-webpack-plugin-sample/blob/master/js/loaderConfig.js) in the sample project for an example of a Dojo loader config that uses the [environment](#environment) and [buildEnvironment](#buildenvironment) options to specify different config paths for build time vs run time. The config also supports running the sample app as a non-packed application with Dojo loaded from a CDN.
79
77
@@ -247,10 +245,37 @@ plugins: [
247
245
248
246
#### Overriding profile features
249
247
250
-
By default, the embedded loader is built using the static has features defined [here](https://github.com/OpenNTF/dojo-webpack-plugin/blob/master/buildDojo/loaderDefaultFeatures.js). You may override these features by providing an optional, third argument to the build script which specifies the features you want to override as a JSON string. For example, if you specify the [loaderConfig](#loaderconfig) option as an object, or a function that returns an object (as opposed to specifying it as a module name), then you can make the embedded loader smaller by omitting the config api. This would be done as follows:
248
+
By default, the embedded loader is built using the static features defined [here](https://github.com/OpenNTF/dojo-webpack-plugin/blob/master/buildDojo/loaderDefaultFeatures.js). You may override these features by providing an optional, third argument to the build script which specifies the features you want to override as a JSON string. For example, if you specify the [loaderConfig](#loaderconfig) option as an object, or a function that returns an object (as opposed to specifying it as a module name), then you can make the embedded loader smaller by omitting the config api. See [The `dojo-config-api` feature](#the-dojo-config-api-feature). This would be done as follows:
A modest reduction in the size of the bootstrap code can be realized by excluding the code needed for loading and parsing the Dojo loader config from the embedded Dojo loader. This can only be done if the [loaderConfig](#loaderconfig) option is specified as an object or function. It cannot be done if the [loaderConfig](#loaderconfig) option is specified as a module name because of the need for the embedded Dojo loader to process the loader config on the client.
255
+
256
+
When using an embedded Dojo loader that does not include the config API, post-processed config objects generated at build time are serialized to the application and used to initialize the embedded loader at application run-time. The pre-processed config object (e.g. `paths`, `packages`, `aliases`, `maps`, etc.) are not serialized to the application because they are not needed by Dojo. If your application requires access to these config properties at runtime (e.g. from `dojoConfig` or `require.rawConfig`), then don't use this feature.
257
+
258
+
This plugin detects at application build time whether or not the embedded Dojo loader includes the config API and emits the code for initiailzing the application as appropriate for the type of loader provided.
259
+
260
+
There are two ways to use the embedded Dojo loader without the config API.
261
+
262
+
1. If the plugin is building the loader automatically at application build time (i.e. you are not specifying the [loader](#loader) option), then you can specify the `dojo-config-api` has feature with a value of 0 or false in the Dojo loader config. Note that the `dojo-config-api` has feature is ignored if the [loaderConfig](#loaderconfig) option specifies a module name.
263
+
<!-- eslint-disable no-undef, semi -->
264
+
```javascript
265
+
plugins: [
266
+
new DojoWebpackPlugin({
267
+
loaderConfig: {
268
+
paths: {/*...*/},
269
+
packages: [/*...*/],
270
+
has: {'dojo-config-api':false}
271
+
}
272
+
// ...
273
+
})
274
+
]
275
+
```
276
+
277
+
1. If you are specifying a pre-built embedded loader using the [loader](#loader) option, then build the loader without the config API as described in [Overriding profile features](#overriding-profile-features). Note that an exception will be thrown if the [loaderConfig](#loaderconfig) option specifies a module name and the provided loader does not include the config API.
278
+
254
279
# ES6 Promise dependency in Webpack 2.x
255
280
256
281
Webpack 2.x includes code in your packed application that uses ES6 Promise. If you need to support browsers that lack ES6 Promise support (e.g. IE 11), then you will need to provide this capability in your application. This plugin provides a tiny wrapper module named [dojoES6Promise](https://github.com/OpenNTF/dojo-webpack-plugin/blob/master/amd/dojoES6Promise.js) that implements ES6 Promise using dojo/Deferred. All you need to do is include this module as an AMD dependency in your application. See [bootstrap.js](https://github.com/OpenNTF/dojo-webpack-plugin-sample/blob/master/js/bootstrap.js) in the sample application for an example.
0 commit comments