d4551f49f5
* Minify stream, add stream stuff to releases again * Kill off a lot of tech debt, drop internal utilities from npm 1. Kill `module/`, internalize `bundler/`, privatize `test-utils/` We've been telling people to move elsewhere from these for a while, and it's about time we just pull the plug here and finally remove them. - We officially removed the bundler from the public API in v2.0, and that was the only one of these that was ever publicly documented. Usage should be low enough by now it shouldn't break anyone- I'm not seeing bundler bugs being reported anymore, either. - The `module/` utility was so narrow and caveat-filled that I'm not sure anyone really used it (even us core Mithril devs never really used it), and we only had it documented in the repo folder it lived in. I think only one bug was ever filed, and it's because it somehow ended up completely non-functional without any of us realizing it. - The test utilities were meant to be internal from day 1, but people started using it despite us core developers constantly telling people to look elsewhere and even the docs recommending specific alternatives without mention of our internal mocks. (Now if people would RTFM, that'd be nice...) 2. Add dedicated HTML test files to verify ospec and the promise polyfill, and ensure the promise tests are in pure ES5. These are made specially for those and should be much easier to just run now. 3. Fix the benchmark script to use the real DOM in browsers and to not require as many dependencies to create. Also, tweak them to be much more effective and precise on what's being tested. Previously, it was rendering to the HTML file itself, while now it's rendering to the `body`. This means in browsers, it's triggering layout and everything, benchmarking how well Mithril optimizes for style and layout recalcs, too. It also puts some pressure on the hyperscript parser attribute application, so that can be noticed as well. * Update dependencies
22 lines
2.2 KiB
Markdown
22 lines
2.2 KiB
Markdown
# bundler.js
|
|
|
|
Simplistic CommonJS module bundler
|
|
|
|
Version: 0.1
|
|
License: MIT
|
|
|
|
## About
|
|
|
|
This bundler attempts to aggressively bundle CommonJS modules by assuming the dependency tree is static, similar to what Rollup does for ES6 modules.
|
|
|
|
Most browsers don't support ES6 `import/export` syntax, but we can achieve modularity by using CommonJS module syntax and transpiling it.
|
|
|
|
Webpack is conservative and treats CommonJS modules as non-statically-analyzable since `require` and `module.exports` are legally allowed everywhere. Therefore, it must generate extra code to resolve dependencies at runtime (i.e. `__webpack_require()`). Rollup only works with ES6 modules. ES6 modules can be bundled more efficiently because they are statically analyzable, but some use cases are difficult to handle due to ES6's support for cyclic dependencies and hosting rules. This bundler assumes code is written in CommonJS style but follows a strict set of rules that emulate statically analyzable code and favors the usage of the factory pattern instead of relying on obscure corners of the Javascript language (hoisting rules and binding semantics).
|
|
|
|
### Caveats
|
|
|
|
- Only supports modules that have the `require` and `module.exports` statement declared at the top-level scope before all other code, i.e. it does not support CommonJS modules that rely on dynamic importing/exporting. This means modules should only export a pure function or export a factory function if there are multiple statements and/or internal module state. The factory function pattern allows easier dependency injection in stateful modules, thus making modules testable.
|
|
- Changes the semantics of value/binding exporting between unbundled and bundled code, and therefore relying on those semantics is discouraged.
|
|
- Top level strictness is infectious (i.e. if entry file is in `"use strict"` mode, all modules inherit strict mode, and conversely, if the entry file is not in strict mode, all modules are pulled out of strict mode)
|
|
- Currently only supports assignments to `module.exports` (i.e. `module.exports.foo = bar` will not work)
|
|
- It is tiny and dependency-free because it uses regular expressions, and it only supports the narrow range of import/export declaration patterns outlined above.
|