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.
This included removing some internal version constraints. It would be
nice if package A could say "use B@2.0.0" (when both have changed), but
when they're both in the release, we need to make a release that has a
B@2.0.0-rc in it, which doesn't match that constraint. Fortunately,
constraints aren't necessary within a release anyway.
Implements caching for single-file compilers (those that don't implement
'import' directives) as a superclass, CachingCompiler.
Used in coffeescript and templating.
Previously, registerCompiler was enabled by the *real* package
`compiler-plugin`, which arranged to only be available in versions of
the tool that support registerCompiler via... well, mostly via wishful
thinking.
Now this is implemented via a fake package called
isobuild:compiler-plugin. "isobuild" is a real Atmosphere organization
that will never publish any packages. The tool pretends that packages
isobuild:compiler-plugin@1.0.0, isobuild:linter-plugin@1.0.0, and
isobuild:minifier-plugin@1.0.0 exist, and carefully arranges for them to
be avoided in the actual process of building and app; they just are
referenced in Version Solver.
When we add future features like this, users of this version of Meteor
who try to depend on packages that need the feature will get a nice
error message pointing to
https://github.com/meteor/meteor/wiki/Isobuild-Feature-Packages
Users of current versions of Meteor who try to depend on packages that
require isobuild:compiler-plugin will get a slightly confusing message
about isobuild:compiler-plugin not existing. Users of current versions
of Meteor who try to depend on packages only some of whose versions
require isobuild:compiler-plugin will get a version that doesn't require
it.
This breaks the path meteor-platform -> webapp -> boilerplate-generator
-> spacebars-compiler -> minifiers which ended up shipping all of uglify
with each built app, even though the code generated in
boilerplate-generator is just eval'd without ever being shown to humans.
Beautification still works on JS generated by templating (*.html),
though.
A merge of the windows-cordova branch did not increment the version numbers
of some packages before adding pre-release versions. This causes constraint
solver errors, when, for example, trying to build a release from devel. This
change should fix the most obvious candidates.
