Rename 'mode' and 'minify' to 'minifyMode' consistently (including in
minifier plugin API).
Make minifyMode default to 'development' (fixes some other old bundler
tests).
This doesn't make bundler-assets pass but it gets farther along.
Note that this test started as a test of parseStack when a filename
contained a colon, and it no longer tests that since around 1.1 we
started trying to avoid putting colons in generated filenames for
Windows compatibility. But it still caught this legacy handler bug!
Exit codes are 0-255 in Unix; there is no -1. Also there's no reason to
use the fancy throw ExitWithCode in the top-level command, which can
just return.
In the past, `api.addFiles('foo.gif')` would make foo.gif an asset if
there was no extension handler for gif active. In fact, it would make
it a dual client/server asset even if that was unintentional.
This led to a few problems:
(a) People often left out 'client' and ended up packaging an unnecessary
second server copy of the asset
(b) The implementation meant that `api.addFiles('foo.css')` would actually
add foo.css as a static asset on the server (this was already fixed
on batch-plugins via explicitly looking for wrong-arch
classifications)
(c) Now that we have linters, if a file is used by a linter but not by a
compiler (eg linter config files), there was no way to say in a
package "add this file, but just for linters, don't make it a static
asset too".
These are only really issues in packages, not apps. In apps, we avoid
them by only marking things as static assets if they are in public or
private (and not letting those things be considered as other kinds of
sources).
This is a backwards-incompatible change, but it does not affect apps or
published packages, just packages built from source.
We added it to make the use of getSourcesFunc by the linter more
efficient, but the linter is actually looking for a different set of
files than the compiler!
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.
If the same ProjectContext calls the PackagesResolver
multiple times and the ConstraintSolver.Input structure
is identical, reuse the same answer. We still ask the
tool for the catalog data, which currently goes to sqlite
(taking ~70ms in the app tested), but we skip creating a
CS.Solver and a Logic.Solver and running them (~450ms).
Note that if a new ProjectContext is created (not sure when
that happens?), there's no caching across that.
If the METEOR_PROFILE env variable is set to a number, it would be used
a filter bound for reporting.
Useful to eliminate the noise of small and fast functions.
Ex.: `env METEOR_PROFILE=100 ./meteor` will only print sections that
took more than 100ms to complete.
This helps especially for app files changes:
- usually a file is changed alone, the imports are not changed
- the changed imports do not affect individually prelinked files (thus "prelink")
- there is no point re-prelinking all files when one is changed
Saves 400ms on an internal benchmark for a mobile edu app
An optimization to avoid writing the same files over and over again.
Tested only on Mac OS X.
There is a potential problem with this approach on Windows, since the
way processes retain open files is different.
On Linux (and I assume, OS X, too), when a process has a file open, it
reads the file from a memory snapshot loaded by OS. The OS also would
increment the reference count for that file, so even if it is unlinked
from the FS, OS would still keep it available as long as the process
keeps it open.
When we want to replace a file under a running Meteor app process, we
first delete the old built file and then write a new file to the same
path. In my understanding, it would force the OS to assign a different
inode for the new file, so the old file and the new file will be
different. Then, we either restart the app process, or signal it to
reload its assets, so it reads the new files, releasing the older ones.
I need to verify this understanding with somebody who actually knows how
OS and FS work.
