8000 minor #10692 Changing the wording around module.exports (ProtonScott,… · symfony/symfony-docs@4353f91 · GitHub
[go: up one dir, main page]

Skip to content

Commit 4353f91

Browse files
committed
minor #10692 Changing the wording around module.exports (ProtonScott, javiereguiluz)
This PR was submitted for the 4.1 branch but it was merged into the 3.4 branch instead (closes #10692). Discussion ---------- Changing the wording around module.exports Hello! I just want to point something out here: Using the commonjs format (require() and module.exports, though node does add some additional things on top of that spec) *is not* the same, or even roughly the same, which is implied/stated by this line here: >Instead of using require and module.exports like shown above, JavaScript has an alternate syntax, which is a more accepted standard. Choose whichever you want: they do the same thing. I propose a minor edit here, which is that we actually want to clarify that the ECMAScript standard that has been finalized (often this is known as ES6 or ES2015. There was a minor revision in there but thats long since passed in either case) and one of the purposes, per the Module spec, is that this is the standard for which modules will be *native to the browser*. (In the evergreen versions of Safari, Chrome, Firefox, and I think even Edge now, you can use `<script type="module" src="somemodule.js">` and it will work fine). They are also the only official way of using dynamic imports, as highlighted [in your own documentation](https://symfony.com/doc/current/frontend/encore/code-splitting.html) in a way that I think gets the point across very well. I think this is very misleading otherwise. You do in fact see a performance decoupling bundling the commonjs modules, as webpack can't take advantage of code splitting with dynamic imports without using ECMAScript modules (more or less, from a high level view). Of course I'm okay changing whatever wording as needed, but I think we should really point out that require() and import are two *very* different beasts, and I am happy to write up as to way, give links, etc. <!-- If your pull request fixes a BUG, use the oldest maintained branch that contains the bug (see https://symfony.com/roadmap for the list of maintained branches). If your pull request documents a NEW FEATURE, use the same Symfony branch where the feature was introduced (and `master` for features of unreleased versions). --> Commits ------- d8ba869 Minor tweaks 577e35e Changing the wording around module.exports
2 parents 9b7f158 + d8ba869 commit 4353f91

File tree

1 file changed

+3
-2
lines changed

1 file changed

+3
-2
lines changed

frontend/encore/simple-example.rst

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -180,8 +180,8 @@ The import and export Statements
180180
--------------------------------
181181

182182
Instead of using ``require`` and ``module.exports`` like shown above, JavaScript
183-
has an alternate syntax, which is a more accepted standard. Choose whichever you
184-
want: they do the same thing.
183+
provides an alternate syntax based on the `ECMAScript 6 modules`_ that includes
184+
the ability to use dynamic imports.
185185

186186
To export values, use ``exports``:
187187

@@ -345,3 +345,4 @@ Encore support many more features! For a full list of what you can do, see
345345
`Encore's index.js file`_. Or, go back to :ref:`list of Encore articles <encore-toc>`.
346346

347347
.. _`Encore's index.js file`: https://github.com/symfony/webpack-encore/blob/master/index.js
348+
.. _`ECMAScript 6 modules`: https://hacks.mozilla.org/2015/08/es6-in-depth-modules/

0 commit comments

Comments
 (0)
0