If you're subclassing `CachingCompiler` or `MultiFileCachingCompiler`, you
can now implement a `compileOneFileLater` (emphasis on `Later`) to opt into
the new lazy compilation strategy.
If you implement this method, and `inputFile.supportsLazyCompilation` is
true, then the `addCompileResult` will not be called, though it is
probably a good idea to keep any existing `addCompileResult` methods, just
in case `inputFile.supportsLazyCompilation` is not truthy.
This will be an important part of a proper solution to the issues I
described (but failed to fix) in my broken PR #9968.
Because the files are in an imports/ directory, they are still considered
lazy, so they will not be applied to the document unless imported from JS.
Related: #6037
@dgreensp:
The more I think about it, the more I don't like naming a directory
after a singular noun like `import`. We have `packages/` already,
and I want to put my modules in a directory called `modules/`, not
`module/`, just like I don't want to put my assets in `asset/`, or
my stylesheets in `stylesheet/`, etc. It's ok to have a singular
suffix and a plural directory name: to have `.import` files go in
`imports` or `.template` files go in `templates`. Directory names
like `doc` and `lib` follow an old Unix convention of three-letter
names. And if the `import` directory name is actually a verb, not a
noun, that is confusing because putting files in the `import`
directory does not import them. It just causes them to be
considered imports (noun).
In addition to the old `*.lessimport` and `*.import.less` mechanisms for
telling the `less` package that a file isn't a root, you can also put it
in an `import` subdirectory or pass `{isImport: true}` to
`api.addFiles`. We no longer will need to rename every less file when we
upgrade.
Next commit will revert the changes to examples and docs.
Also combine the two coffee registerCompiler calls into one
it's a bad on-disk cache that should be improved to not write out all
the unchanged files every time too. but the tests do show that it skips
the unnecessary recompile
less doesn't use an on-disk cache yet
Specifically, ensure that we don't even include client-specific files in
the server WatchSet by making sure we pass a precise set of extensions
to initFromAppDir. We still also rule out wrong-arch files at a later
stage too (because sourceExtensions only affects initFromAppDir).
Without the change to compiler.js, the final test (adding
yet-another-root.main.less) restarts the server rather than printing
"Client modified -- refreshing".
Regression introduced by the CSS watching code (specifically, f230eba62)
by the sourceIsWatched check. We need to be able to tell the difference
between "source handler didn't do anything because there was an error"
and "source handler didn't do anything because it's web-specific and
this is an os arch".
A simple fix would have been to interpret compileStep.error as
"sourceIsWatched = true", but I didn't think of that until after doing
it the slightly more complicated but more precise way :)
Also, ensure that if the runner rebuilds the client and there's an
error, it properly kills the app process (and the watchers and the
keepalive interval, etc).
Cordova projects often have a different set of files than web targets,
so we would like to be able to target different client architectures in
our bundles. Ideally, we allow the user to use arbitrary client
architectures - but this patch is a step in the right direction by
abstracting out more of the hard coded "browser"/"os" lines.
We accomplish this separation in a backwards compatible way by allowing
api.___ commands to target a "client" architecture. For example,
api.addFiles('a.js', 'client') adds 'a.js' to both the 'client.browser'
and 'client.cordova' targets.
Effects on 0.9 packaging stuff: packages don't have to change, but the
"data.json" file in ".meteor0" has "browser" in some places. We think we
have to fix the troposphere code where this data.json is created.
Some plugins will also be backwards-incompatible with this change, since
many have a "clientArch.matches("browser")" line in the plugin
code. Ideally, we fix plugins so that this stops being an issue, but for
now package authors can just patch that line.
At the compiled (unipackage) level the new names are 'web.browser' and
'web.cordova', replacing 'browser'. In package.js, the new names are
'client.browser' and 'client.cordova', serving as an adjunct to 'client'.
