Also, "marketing material" doesn't seem like an accurate description of the page on the Meteor site as it's more of a high level description of the component.
1. Make a package called `static-html` that just compiles `<head>` and `<body>` tags inside `.html` files. Much like templating but without the templates.
2. Refactor `templating` to avoid duplicating code.
Split out code that would be shared between `templating` and `static-html` into a new `templating-tools` package. These tools could also be used to simplify implementation of other build plugins, like `simple:markdown-templating`.
This also has the added benefit of moving as much code as humanly possible out of the `templating` package, so that it can be reused in other packages.
1. `templating-tools` package and its README
2. `static-html` package and its README
3. `caching-html-compiler` is not new code; it is just code factored out of the batch plugin version of `templating`, but the README and some comments are new.
1. `tools/tests/static-html.js` tests static html and error handling
2. `templating-tools/html-scanner-tests.js` tests `scanHtmlForTags` and `compileTagsWithSpacebars` together.
All unit tests pass on this branch.
The es5-shim package can be removed by expert users who do not wish to
support older browsers, or who wish to support older browsers using a
different shim library.
To enable that use case, we do not register a strong dependency on the
es5-shim package in the core meteor package, but we do ensure that
es5-shim loads first when it is installed.
The Babel parser is faster, it has to be installed (unlike Esprima, which
can be removed after a few more changes like this), and better matches the
parsing we do for ECMAScript transpilation.
- Upgrade to a newer (unreleased) version which supports
function k({} = {}) {}
and doesn't also crash
- Filter out boring warnings
- Don't use ES7 syntax that JSDoc doesn't support in one file that
has JSDoc in it
I thought we could rely on isobuild:compiler-plugin for this, but it's
not good enough: a package could have dependencies that are satisfiable
without choosing a dependency version with a compiler plugin, yet choose
that dependency version at publish time and become ineligble for legacy
builds.