-
Notifications
You must be signed in to change notification settings - Fork 73
Description
All the browsers that we support have had ES6 modules available for a long time now.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules
Refactor to use ES6 modules. There will need to be some investigation needed to figure out how best to make this work. We can probably put all the module import statements in the bare_header function of html.py in a nonce.
Every javascript module will need rewriting so that instead of being in a wrapped object, functions and members become top-level effectively, as we'd be using the import { * as ModuleName} from "file" syntax in order to scope them to ModuleName. There will be unforeseen side-effects from doing this and things that break. Will this still work ok in common.js where they're all added to the module list for route evaluation?
This will probably be the death of the rollup build time stuff, but we can still minify the modules. Is it worth reviewing whether we still need babel? We don't use any really advanced JS features so I suspect babel isn't doing much. We originally added it for await/async support on older browers - not sure if this is necessary.
What are the benefits of doing this?
- Using the module loader system instead of rolling up a giant file, so easier to debug in production
- Standards compliant js
- Intellisense/code completion will work with vscode when developing, vscode extensions like "find global js" sort of work but are really slow and painful (and it's not the fault of the extension)