Update documentation examples to ES6 #7636

src/components/Footer/Footer.jsx

@@ -39,7 +39,10 @@ const Footer = () => (
         <Link className="footer__link" to="/branding/">
           Branding
         </Link>
-        <Link className="footer__link" to="https://discord.com/invite/5sxFZPdx2k">
+        <Link
+          className="footer__link"
+          to="https://discord.com/invite/5sxFZPdx2k"
+        >
           Discord
         </Link>
         <Link

src/content/api/cli.mdx

@@ -503,7 +503,7 @@ In case your configuration file exports multiple configurations, you can use `--
 Consider the following `webpack.config.js`:
 
 ```js
-module.exports = [
+export default [
   {
     output: {
       filename: './dist-first.js',
@@ -617,7 +617,7 @@ In addition to the customized `env` showed above, there are some built-in ones u
 Note that you can not access those built-in environment variables inside the bundled code.
 
 ```javascript
-module.exports = (env, argv) => {
+export default (env, argv) => {
   return {
     mode: env.WEBPACK_SERVE ? 'development' : 'production',
   };
@@ -649,7 +649,7 @@ When the `mode` option is not specified in the configuration, you can use the `-
 If your configuration exports a function, the value of `--config-node-env` is assigned to mode after the function returns. This means that `mode` will not be available in the function arguments (`env` and `argv`). However, the value of `--config-node-env` is accessible as `argv.nodeEnv` within the function and can be used accordingly.
 
 ```javascript
-module.exports = (env, argv) => {
+export default (env, argv) => {
   console.log(argv.defineProcessEnvNodeEnv); // 'production' if --config-node-env production is used
   return {
     // your configuration

src/content/api/loaders.mdx

@@ -48,20 +48,20 @@ Either `return` or `this.callback` can be used to return the transformed `conten
 **sync-loader.js**
 
 ```javascript
-module.exports = function (content, map, meta) {
+export default function (content, map, meta) {
   return someSyncOperation(content);
-};
+}
 ```
 
 The `this.callback` method is more flexible as you pass multiple arguments instead of using `content` only.
 
 **sync-loader-with-multiple-results.js**
 
 ```javascript
-module.exports = function (content, map, meta) {
+export default function (content, map, meta) {
   this.callback(null, someSyncOperation(content), map, meta);
   return; // always return undefined when calling callback()
-};
+}
 ```
 
 ### Asynchronous Loaders
@@ -71,36 +71,36 @@ For asynchronous loaders, you can return the transformed `content` from an `asyn
 **async-loader.js**
 
 ```javascript
-module.exports = async function (content, map, meta) {
+export default async function (content, map, meta) {
   var result = await someAsyncOperation(content);
   return result;
-};
+}
 ```
 
 Or you can use [`this.async`](#thisasync) to retrieve the `callback` function:
 
 **async-loader-with-callback.js**
 
 ```javascript
-module.exports = function (content, map, meta) {
+export default function (content, map, meta) {
   var callback = this.async();
   someAsyncOperation(content, function (err, result) {
     if (err) return callback(err);
     callback(null, result, map, meta);
   });
-};
+}
 ```
 
 **async-loader-with-multiple-results.js**
 
 ```javascript
-module.exports = function (content, map, meta) {
+export default function (content, map, meta) {
   var callback = this.async();
   someAsyncOperation(content, function (err, result, sourceMaps, meta) {
     if (err) return callback(err);
     callback(null, result, sourceMaps, meta);
   });
-};
+}
 ```
 
 T> Loaders were originally designed to work in synchronous loader pipelines, like Node.js (using [enhanced-require](https://github.com/webpack/enhanced-require)), _and_ asynchronous pipelines, like in webpack. However, since expensive synchronous computations are a bad idea in a single-threaded environment like Node.js, we advise making your loader asynchronous if possible. Synchronous loaders are ok if the amount of computation is trivial.
@@ -112,13 +112,13 @@ By default, the resource file is converted to a UTF-8 string and passed to the l
 **raw-loader.js**
 
 ```javascript
-module.exports = function (content) {
+export default function (content) {
   assert(content instanceof Buffer);
   return someSyncOperation(content);
   // return value can be a `Buffer` too
   // This is also allowed if loader is not "raw"
-};
-module.exports.raw = true;
+}
+export const raw = true;
 ```
 
 ### Pitching Loader
@@ -130,7 +130,7 @@ T> Loaders may be added inline in requests and disabled via inline prefixes, whi
 For the following configuration of [`use`](/configuration/module/#ruleuse):
 
 ```javascript
-module.exports = {
+export default {
   //...
   module: {
     rules: [
@@ -160,26 +160,26 @@ So why might a loader take advantage of the "pitching" phase?
 First, the `data` passed to the `pitch` method is exposed in the execution phase as well under `this.data` and could be useful for capturing and sharing information from earlier in the cycle.
 
 ```javascript
-module.exports = function (content) {
+export default function (content) {
   return someSyncOperation(content, this.data.value);
-};
+}
 
-module.exports.pitch = function (remainingRequest, precedingRequest, data) {
+export const pitch = function (remainingRequest, precedingRequest, data) {
   data.value = 42;
 };
 ```
 
 Second, if a loader delivers a result in the `pitch` method, the process turns around and skips the remaining loaders. In our example above, if the `b-loader`s `pitch` method returned something:
 
 ```javascript
-module.exports = function (content) {
+export default function (content) {
   return someSyncOperation(content);
-};
+}
 
-module.exports.pitch = function (remainingRequest, precedingRequest, data) {
+export const pitch = function (remainingRequest, precedingRequest, data) {
   if (someCondition()) {
     return (
-      'module.exports = require(' +
+      'export default import.meta.require(' +
       JSON.stringify('-!' + remainingRequest) +
       ');'
     );
@@ -397,10 +397,10 @@ All dependencies of the resolving operation are automatically added as dependenc
 Information about HMR for loaders.
 
 ```javascript
-module.exports = function (source) {
+export default function (source) {
   console.log(this.hot); // true if HMR is enabled via --hot flag or webpack configuration
   return source;
-};
+}
 ```
 
 ### this.hashDigest
@@ -452,7 +452,7 @@ An alternative lightweight solution for the child compiler to compile and execut
 **webpack.config.js**
 
 ```js
-module.exports = {
+export default {
   module: {
     rules: [
       {
@@ -624,7 +624,7 @@ Access to the following utilities.
 **my-sync-loader.js**
 
 ```js
-module.exports = function (content) {
+export default function (content) {
   this.utils.contextify(
     this.context,
     this.utils.absolutify(this.context, './index.js')
@@ -637,7 +637,7 @@ module.exports = function (content) {
   mainHash.digest('hex');
   // …
   return content;
-};
+}
 ```
 
 ### this.version
@@ -711,21 +711,21 @@ Throwing an error from loader:
 **./src/loader.js**
 
 ```javascript
-module.exports = function (source) {
+export default function (source) {
   throw new Error('This is a Fatal Error!');
-};
+}
 ```
 
 Or pass an error to the callback in async mode:
 
 **./src/loader.js**
 
 ```javascript
-module.exports = function (source) {
+export default function (source) {
   const callback = this.async();
   //...
   callback(new Error('This is a Fatal Error!'), source);
-};
+}
 ```
 
 The module will get bundled like this:
@@ -738,7 +738,7 @@ The module will get bundled like this:
 /*! no static exports found */
 /***/ (function(module, exports) {
 
-throw new Error("Module build failed (from ./src/loader.js):\nError: This is a Fatal Error!\n    at Object.module.exports (/workspace/src/loader.js:3:9)");
+throw new Error("Module build failed (from ./src/loader.js):\nError: This is a Fatal Error!\n    at Object.<Module Execution> (/workspace/src/loader.js:3:9)");
 
 /***/ })
 ```
@@ -749,7 +749,7 @@ Then the build output will also display the error (Similar to `this.emitError`):
 ERROR in ./src/lib.js (./src/loader.js!./src/lib.js)
 Module build failed (from ./src/loader.js):
 Error: This is a Fatal Error!
-    at Object.module.exports (/workspace/src/loader.js:2:9)
+    at Object.<Module Execution> (/workspace/src/loader.js:2:9)
  @ ./src/index.js 1:0-25
 ```
 
@@ -801,9 +801,9 @@ The loader could look like this:
 **extract-style-loader/index.js**
 
 ```javascript
-const getStylesLoader = require.resolve('./getStyles');
+import getStylesLoader from './getStyles';
 
-module.exports = function (source) {
+export default function (source) {
   if (STYLES_REGEXP.test(source)) {
     source = source.replace(STYLES_REGEXP, '');
     return `import ${JSON.stringify(
@@ -814,16 +814,16 @@ module.exports = function (source) {
     )};${source}`;
   }
   return source;
-};
+}
 ```
 
 **extract-style-loader/getStyles.js**
 
 ```javascript
-module.exports = function (source) {
+export default function (source) {
   const match = source.match(STYLES_REGEXP);
   return match[0];
-};
+}
 ```
 
 ## Logging

src/content/api/logging.mdx

@@ -50,12 +50,12 @@ export class MyWebpackPlugin {
 **my-webpack-loader.js**
 
 ```js
-module.exports = function (source) {
+export default function (source) {
   // you can get Logger with `this.getLogger` in your webpack loaders
   const logger = this.getLogger('my-webpack-loader');
   logger.info('hello Logger');
   return source;
-};
+}
 ```
 
 As you can see from the above `my-webpack-plugin.js` example, there're two types of logging methods,
@@ -84,12 +84,12 @@ It's advised to use `compilation.getLogger` when plugin/logging is related to th
 
 Runtime logger API is only intended to be used as a development tool, it is not intended to be included in [production mode](/configuration/mode/#mode-production).
 
-- `const logging = require('webpack/lib/logging/runtime')`: to use the logger in runtime, require it directly from webpack
+- `import logging from 'webpack/lib/logging/runtime';`: to use the logger in runtime, import it directly from webpack
 - `logging.getLogger('name')`: to get individual logger by name
 - `logging.configureDefaultLogger(...)`: to override the default logger.
 
 ```javascript
-const logging = require('webpack/lib/logging/runtime');
+import logging from 'webpack/lib/logging/runtime';
 logging.configureDefaultLogger({
   level: 'log',
   debug: /something/,

src/content/api/module-variables.mdx

@@ -36,17 +36,17 @@ Indicates whether or not [Hot Module Replacement](/concepts/hot-module-replaceme
 The ID of the current module.
 
 ```javascript
-module.id === require.resolve('./file.js');
+console.log('Current module ID concept is available via import.meta');
 ```
 
 ## module.exports (CommonJS)
 
 Defines the value that will be returned when a consumer makes a `require` call to the module (defaults to a new object).
 
 ```javascript
-module.exports = function doSomething() {
+export default function doSomething() {
   // Do something...
-};
+}
 ```
 
 W> This CANNOT be used in an asynchronous function.
@@ -56,13 +56,13 @@ W> This CANNOT be used in an asynchronous function.
 This variable is equal to the default value of `module.exports` (i.e. an object). If `module.exports` gets overwritten, `exports` will no longer be exported.
 
 ```javascript
-exports.someValue = 42;
-exports.anObject = {
+export const someValue = 42;
+export const anObject = {
   x: 123,
 };
-exports.aFunction = function doSomething() {
+export function aFunction() {
   // Do something
-};
+}
 ```
 
 ## global (NodeJS)
@@ -170,7 +170,7 @@ If used inside an expression that is parsed by the Parser, the configuration opt
 The resource query of the current module. If the following `require` call was made, then the query string would be available in `file.js`.
 
 ```javascript
-require('file.js?test');
+import 'file.js?test';
 ```
 
 **file.js**
@@ -265,14 +265,12 @@ In modules, `__webpack_exports_info__` is available to allow exports introspecti
 - `__webpack_exports_info__.<exportName>.used` is `false` when the export is known to be unused, `true` otherwise
 
 - `__webpack_exports_info__.<exportName>.useInfo` is
-
   - `false` when the export is known to be unused
   - `true` when the export is known to be used
   - `null` when the export usage could depend on runtime conditions
   - `undefined` when no info is available
 
 - `__webpack_exports_info__.<exportName>.provideInfo` is
-
   - `false` when the export is known to be not provided
   - `true` when the export is known to be provided
   - `null` when the export provision could depend on runtime conditions