Package version unpinning (#7084) removed all exact package@=version
constraints derived from the current release.
As we discovered with Meteor 1.4.2.4 (#8306), this meant releases no
longer had any power to enforce package upgrades, which is why the
follow-up Meteor 1.4.2.5 release (#8311) was necessary.
This commit has the same effect as putting package@version in your
.meteor/packages file for every local/core package that your app uses.
This is a refactor/finishing-move of @c9s's original PR meteor/meteor#7586.
This maintains backward compatibility with PACKAGE_DIRS using the original separator that it expected (':'). Users of the new METEOR_PACKAGE_DIRS variable should use the correct path separator for their platform (`:` on BSD/Linux and `;` on Windows).
Fixesmeteor/meteor#7585Fixesmeteor/meteor#4204
This reverts commit 9e6ebde836.
Now that the `dev_bundle` link is called `.meteor/local/dev_bundle`, and
`.meteor/local` is already ignored, we don't need to ignore
`.meteor/dev_bundle` anymore.
If a developer tried to `meteor update` a project whose `.meteor/release`
file corresponded to a version of `meteor-tool` that no longer exists in
`~/.meteor/packages/meteor-tool`, this code would throw an ENOENT error.
This could be fixed by running `meteor update --release <old release>`
first, but that kind of workaround shouldn't be necessary when updating
Meteor to the latest version.
I'm deliberately leaving in the code to ensure .meteor/.gitignore contains
dev_bundle for now, so that the old file won't get accidentally checked
into anyone's app repository.
I'm deliberately leaving in the code to ensure .meteor/.gitignore contains
dev_bundle for now, so that the old file won't get accidentally checked
into anyone's app repository.
Our old "unit" test mode didn't really enforce "unit-ness" and was perfectly capable of running integration test. So it was confusing to call the two modes unit and integration test modes.
Instead, we call them "test mode" and "full app test mode", run with `meteor test` and `meteor test --full-app`.
The rules for test files were also simplified -- simply *.test[s].* for test mode, and *.app-test[s].* for full app tests. `tests/` directories are simply ignored again.
To avoid solving the full constraint-solver problem when you start your
app with a previousSolution (i.e. .meteor/versions), we first try to
prove that .meteor/versions is correct as far as we can tell while only
loading the package versions mentioned there.
When it works, it saves both disk I/O and logic-solving time, starting
at a couple seconds and potentially much more.
Everything still works if .meteor/versions is missing, or partially or
totally invalid, or mentions package versions that need to be fetched in
a catalog update first, etc.
Previously, we would generate reports on
"Selecting Package Versions" and "Rebuild App".
- Instead of just profiling constraint solving, profile the entire
process of preparing the project via ProjectContext, by giving
each public function that "advances the stage" a Profile.run
(typically prepareProjectForBuild).
- Improve profiler output to better distinguish multiple runs
- Distinguish "Build App" and "Rebuild App"
- Instrument lots of calls that weren't instrumented before
This command builds the app with a different directory for
`.meteor/local`, including built packages and the app database. This
allows running `meteor test-app` and `meteor test` in parallel
for a given app, with DB isolation.
Also, we've changed how test driver packages work (as used for
`meteor test-packages`, like "test-in-browser"). Instead of automatically
running tests when they load, they export a `runTests` function that
you should call when you're ready to run tests.
When running `meteor test-app` or `meteor test-packages` a new additional
last line of code is added that calls `Meteor.startup(...runTests()...)`
TODO:
* Implement `testOnly` packages. The current pattern of reading a global
from `package.js` won't work for published packages, which are stored
as metadata, not code.
* Let you choose a test driver package as an argument to `meteor test-app`
* Demonstrate that a Mocha test and driver package are possible to write.
* Expose Meteor.isTest, Meteor.isIntegrationTest, Meteor.isUnitTest
* Implement `meteor test-app --unit` which only loads test files
* `meteor test-app` should load ALL *.tests?.* files, including ones
inside imports/ directories
`projectConstraintsFile.addConstraints(['foo'])` is wrong because 'foo'
is supposed to be a constraint object, not a string. However, it would
quietly add a blank line to .meteor/packages! Now we detect this
mistake, and we also provide addPackages(['foo']).
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?)
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.
