It's very useful to be able to include code only in production. It's
useful for React integration, but presumably also for many apps.
* Add prodOnly boolean flag alongside debugOnly in Package.describe
* Packages the set prodOnly to true auto-depend on isobuild:prod-only
(making them error in the old tool where prodOnly isn't supported)
* The `includeDebug` boolean build option is replaced by a string
named buildMode, which can be 'development' or 'production', just
like minifyMode.
Tested by self-test.
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.
It now runs basically the same caching test as 'less'.
The implementation has been made to be a bit more like 'less'; eg, using
empty string instead of `__app__` to mean the app, and consistently
making pathInPackage not start with a slash.
Implements caching for single-file compilers (those that don't implement
'import' directives) as a superclass, CachingCompiler.
Used in coffeescript and templating.
processFilesForTarget -> processFilesForBundle
Since the minifiers work on the output of compilers and linkers, there
is no a good definition of a "target" there. "Bundle" is a general term
that we use to describe the whole compiled app with all the packages.
The exact borderline between "Isobuild" and "the tool" is a little hazy,
but the idea is that "Isobuild" is the part that you could imagine being
embedded in a non-command-line build tool. It's not about commands or
UI, but just about building packages and apps.
A next step could be moving things that are strictly "the command-line
tool" into their own subdir, and leaving the top directory mostly just
for shared utilities like buildmessage. (Which could even go in a utils
subdir?)
For some reason I decided that tests should, on cleanup, stop their
runs *and not wait for the stop to take effect* before running the next
test. Maybe this could be reconsidered but for now, explicitly stop this
run (and wait) so the next test (npm: npm) doesn't fail.
