The breaking change in the latest version is that the Fiber constructor is
no longer included as a meteor-promise dependency, but must be supplied by
assigning to Promise.Fiber.
Implements caching for single-file compilers (those that don't implement
'import' directives) as a superclass, CachingCompiler.
Used in coffeescript and templating.
If you're running from a checkout but your project has a non-none
release file, the release file should always be ignored. But this one
bit of code (basing the package update code on the post-update release)
paid attention to it anyway. This tended to lead to a lot of errors
like:
No version of webapp satisfies all constraints: @=1.2.1, @=1.2.0
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.
Fixes 3 issues:
- The error detection code in linker.fullLink was buggy.The goal of this
code was to convert an error from findAssignedGlobals into empty
linked output. But buildmessage.jobHasMessages() wasn't precise
enough; if a much larger job had any errors, linker.fullLink would
incorrectly return empty linked output here. (Worse, it got cached in
memory, so the incorrect result would recur on future links!) The fix
is to make the scope of the error detection more targeted.
- OK, now it's OK to cache error outputs from linker.fullLink, because
they're at least only occuring on real errors, right? Wrong... we
shouldn't cache the error return value without also caching the *error
itself*. In this case, we just change the cache to not cache erroneous
outputs at all (though we could have instead saved the error and
rethrown it if we got it again).
- When mutating the File to pretend it was empty, we should keep the
sourceHash up to date. (This doesn't seem to be directly causing any
bugs but can't hurt.)
Fixes#4591.
Also, fix the checks around "did we lint anything": checking
isopack.sourceProcessors.linter just checks to see if that package
itself defines any linter, not if any of the packages it uses has
linters.
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.
@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.
js-analyze is a tiny wrapper around esprima and escope. We don't use it
anywhere but in the tool. We even already use esprima in the tool
elsewhere.
It creates a fair amount of additional complexity. None of the other
isopackets are used as part of the isopack-building process, so it has a
bunch of random special case code for it.
