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.
There were a few problems here:
- compiler.lint actually did things that could seriously fail (eg loading
plugins) but used its buildmessage context to return *linter
warnings*. So actual errors got lumped in with warnings and didn't
prevent builds. Fixed this by changing compiler.lint to return linter
warnings as a return value and use its implicit buildmessage context
only for build errors
- We weren't checking for errors after compiler.getMinifiers even though
that loaded plugins and could fail
- We were using _.isEmpty(app.sourceProcessors.linter) to decide in
lintBundle if we should say "no linter warnings" or "no linters were
run", but this is a SourceProcessorSet now, not a dictionary, so we
should have used the isEmpty method instead (so we were getting
unnecessary "No linting errors" messages when there were no linters)
- compiler.compile still tried to run getSourcesFunc even if
initializing the SourceProcessorSets failed
- Printing linter warnings in the runner looked different depending on
whether it was right after doing a client refresh or not
- We were doing a temporary log of "Linting your app" and immediately
logging "Linted your app". The point of temporary logs is to display
while long processes run, but since linting is integrated, this didn't
really make sense. (Really we need to better integrate the progress
bar and runlog, since progress fulfills most of the needs formerly
done by the runlog.)
This is in addition to registering for extensions. Note that only the
new SourceProcessor APIs allow this, not registerSourceHandler.
The filename in question is the basename of the file. The file can be
found in any directory in any package. If you want to be more picky,
you can just ignore other ones in your processFilesForTarget.
This introduces the SourceProcessorSet abstraction, which simplifies a
lot of repeated code around matching filenames with processors and
avoiding duplicates.
Missing tests.
See also #3985.
There are a few different times when we detect duplicate compiler
extensions.
(a) We detect them in Plugin.registerCompiler if a single
isopack itself registers duplicate extensions.
(b) When compiling a unibuild in compiler.compile, we check to see if a unibuild's
plugin-providing dependencies overlap.
(c) When preparing a unibuild for bundle-time source processing, we
check the same condition.
(Why do we need to re-check in (c)? If a unibuild was published and
passed (b) at publish time but is being bundled with different versions
of dependencies, it might fail (c).)
There were a few fixes here:
- In compiler.js (b), if we detected a duplicate extension, the code to get
the name of the conflict package was wrong and could throw.
- In compiler-plugin (c), we just weren't using buildmessage.
With just those fixes, we would actually see *both* kind of errors show
up if the error was in the app rather than a package, because
bundler.bundle didn't actually bail out on error after compiler.compile!
So we added that fix too, with a relatively conservative WatchSet.
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
Combine BuildPluginDefinition/CompilerPlugin into SourceProcessor. We
don't actually need to ever regenerate the userPlugin objects unless
we're re-loading the Isopack that contains the plugin.
This should allow for in-memory caching in your compiler plugin.
@benjamn convinced me that line numbers are still nice, and especially
so with the changes that let them come from original source files. And
due to
b556e62262 (commitcomment-11437623)
noLineNumbers currently totally disables source maps, which is silly.
This has "declaredExports" instead of "packageVariables" and doesn't
contain prelink resources.
The backwards-compatibility mode knows how to read prelink resources and
packageVariables but doesn't write the prelink resource yet.
(Specifically, the isopack-2-unibuild unibuild format which only lives
in isopack-2 isopacks.)
When saving an isopack, we always save as isopack-2, and if the only
"source"s are CSS and JS we also try to make an isopack-1 version if
we're publishing the package (or saving it to our tropohouse). If we're
just saving it to an app-specific IsopackCache, we don't bother to
create the old version (if an old version of the tool sees this app's
IsopackCache it will have a non-matching BUILT_BY and rebuild the
isopack).
This commit only implements the CSS side of things; the JS side will be
harder (we'll be putting multiple JS sources into the new isopack but
one prelink resource into the old one).
