• El patrón del módulo se utilizó antes de los módulos ES6.
• Objetivo: encapsular funcionalidad, admitir datos privados, exponer API públicas y todo esto se logra mediante el uso de IIFE.

IIFE: Ej. (función(){})();

// IIFE Goal: Create a new scope, return the data just once. All of data inside IIFE will be private as it would inside the fn scope. 
// Using this way, we don't need to call it separately. And it ensures its called only once.
// IIFE is created only once, goal is 'NOT TO REUSE' by executing it multiple times.

// Result of running an IIFE is stored, or else it will disappear simply.
const ShoppingCart2 = (function(){
  const cart = [];
  const shippingCost = 10;
  const totalPrice = 237;
  const totalQuantity = 10;

  const addToCart = function(product, quantity){
    cart.push({product, quantity});
    console.log(`${quantity} ${product} added to cart. Shipping cost is ${shippingCost}`);
  };

  const orderStock = function(product, quantity){
    console.log(`${quantity} ${product} ordered from supplier`);
  };
  // Need to return something, in order to return a public API. For that, an object is returned containing stuff which needs to be made public.
  return {
    addToCart,
    cart, 
    totalPrice,
    totalQuantity
  };
})();
// Everything inside the above module is private to the module.
// The above fn returns the object mentioned inside return statement and assign it to the ShoppingCart2 variable mentioned at the start of fn. This IIFE is returned then long ago.
// All this is possible because of closures. Hence, addToCart can acccess the cart variable.

ShoppingCart2.addToCart('apple', 4);
ShoppingCart2.addToCart('pizza', 5);
ShoppingCart2;
ShoppingCart2.shippingCost; // inaccessible.

El patrón Módulo ha estado funcionando incluso antes de los módulos ES6.

Desventaja:

1. Ahora, si queremos un módulo por archivo, como lo hemos hecho con los módulos ES6, entonces es necesario crear y vincular varios scripts dentro del archivo HTML.
2. El orden de carga del script también importará.
3. Todas esas variables vivirán en un ámbito global.

Además de los módulos y patrones de módulos nativos de ES6, JS también admitía otros sistemas de módulos que no eran nativos de JS. Ex. AMD, CommonJS
Ex. Los módulos CommonJS se utilizan en Node.js durante toda su existencia. Recientemente se han implementado módulos ES6 en Node.js
Todos los módulos en el repositorio npm todavía usan el sistema de módulos commonJS ya que npm fue diseñado originalmente para node. Sólo más tarde, npm se convirtió en el repositorio de todo el mundo JS. Por lo tanto, básicamente estamos estancados con CommonJS. Por lo tanto, todavía es necesario prestar atención a CommonJS como su implicación en Node.js
Al igual que el módulo ES6, 1 archivo es 1 módulo en CommonJS.
El código commonJS no funcionará en el navegador, pero sí en node.js
Los módulos ES eventualmente reemplazarán todos los sistemas de módulos, pero a partir de ahora también necesitamos usar commonjs.

la palabra clave de exportación es un objeto que no está definido en nuestro código ni en el navegador.

// EXPORT
export.addToCart = function(product, quantity){
    cart.push({product, quantity});
    console.log(`${quantity} ${product} added to cart. Shipping cost is ${shippingCost}`);
};

// IMPORT: is similar to ES Modules but would use a require fn.
// require is not defined in browser env but its defined in node env as its a part of commonjs
const addToCart = require('./shoppingCart.js')