js module notes for team dojo

js_module_notes.txt

different kinds of modules through JS history
  name              year  sync  async   encapsulatable  immutable     dependency defs       dep resolution  code example
  -------
  namespaces        2000: yes   no      no              no            none                  manual          var App = {};
  revealing module  2005: yes   no      yes             no            global variables      manual          var myModule = (function($){return {fetch:$.get}})(jQuery)
  CommonJS          2009: yes   no      yes             yes           file names            graph           module.exports={foo:'bar'} const foo = require('foo').foo
  AMD               2009: no    yes     yes             no            file names            graph           define(['jQuery','Application'],($,App)=>{}), require('foo',(foo)=>{...use foo...})
  ES modules        2016: yes   yes     yes             yes           sub-file parts        graph           import {foo} from 'foo', export const foo='bar'; import('foo').then((module)=>module.foo)
  * note that programmatic dependency graph resolution is what enables code completion

different ways of identifying modules
  e.g, commonjs = *.cjs or *.js
  e.g, amd = *.js
  e.g, es = *.mjs or *.js
  e.g, iife js = *.mjs or *.js
  package.json "type" field, and "exports" field, and "main" field and "module" field (and others)
  there differences in how different module loaders load them
  there differences in in each module loader's version
  and differences in browser and node version
  differences in browser tags, like <script type="text/javascript"> and <script type="module">

async timing:
  <script async>, <script defer>, import(), AMD's require()

transformations
  handlerbars templates need transpile to js
  typescript needs transpile to js
  certain es6 features transpiled to es5 for certain browsers
  minification

env:
  dev
  ci
  test
  staging
  production

"module": (revisit this based on modules table I created afterward)
  encapsulated code, with defined api
  static
    module: "1 file with 1-n purposes exported" (static file in the file system, that has never executed)
    ^ may be imported from other files and reexported
    builds nowdays make a dependency graph of purposes for tree shaking (dead code elimination)
  runtime
    "Immutable purposes available on an object when it loads"
    e.g. (things that would make app a module even when static),
      App could import other files, and export their purposes (get every purpose on app, but everything needs to load immediately)
      Other files could import app (app has smaller api, and other files use its functionality)
    what we do (namespace):
      An object you can mutate at runtime
      other files import app and break its encapsulation by mutating it (and its other properties)
      (breaks code completion (which depends on static analysis), and makes us dig around to find things that "app" does.)

loading
  sync/async importing modules to the browser or node

Hot Module Loading:

bundling:
  n modules to 1 "bundle" file

chunking:
  
code splitting:
  Per webpack docs: Split your code into various bundles which can then be loaded on demand or in parallel. It can be used to achieve smaller bundles and control resource load prioritization which, if used correctly, can have a major impact on load time.

tree shaking:
  Per webpack docs: Tree shaking is a term commonly used in the JavaScript context for dead-code elimination. It relies on the static structure of ES2015 module syntax, i.e. import and export. The name and concept have been popularized by the ES2015 module bundler rollup.

lazy loading:

upcoming:
  What does snowpack do?
  How to play with repo?
  how to load files differently
  setting up graph based and manual loading
  load order, manual vs graph-based
  bundling dev loading raw files
  Use react components in current framework