From 7a30a00f000d9b1320dd5f7659eac8c95bf69e07 Mon Sep 17 00:00:00 2001 From: Ilya Kantor Date: Mon, 24 May 2021 11:57:17 +0300 Subject: [PATCH] minor fixes --- 1-js/13-modules/01-modules-intro/article.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1-js/13-modules/01-modules-intro/article.md b/1-js/13-modules/01-modules-intro/article.md index 7e250faa..634dc68c 100644 --- a/1-js/13-modules/01-modules-intro/article.md +++ b/1-js/13-modules/01-modules-intro/article.md @@ -191,7 +191,7 @@ In other words, a module can provide a generic functionality that needs a setup. Here's the classical pattern: 1. A module exports some means of configuration, e.g. a configuration object. 2. On the first import we initialize it, write to its properties. The top-level application script may do that. -3. Further imports use the module. +3. Further imports use the module (it's now configured). For instance, the `admin.js` module may provide certain functionality, but expect the credentials to come into the `config` object from outside: