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.
`meteor run` doesn't always write changes to `.meteor/versions`: it only
does so if its release (or checkout-ness) matches `.meteor/release`. So
it preferred to just remember the value of `.meteor/versions` from
rebuild to rebuild rather than forgetting what it knew and re-reading
the possibly-not-updated file.
However, if some other process changes `.meteor/versions`, it would
ignore that change. With this fix, if `.meteor/versions` changes then
that is considered to be the previous versions list, not the last
version list from the same process. For example, this would commonly
happen due to using `meteor update` to update packages (without changing
the tool, which would cause the runner to stop).
Fixes#3582.
When you `meteor publish` a package (not from an app), a
ProjectContext is created that gets the Version Solver
"previousSolution" from the .versions file in the project directory.
From the point of view of the Version Solver, the package itself is
a root dependency, so if the version changes from last time, you
may be asked to pass --allow-incompatible-update! That isn't right.
However, the ProjectContext created by `meteor publish` doesn't know
it is created for a particular package. But it does have the package
marked as "explicitly added." So for now, the simplest thing to do
is to alter the input to the Version Solver based on the value of
explicitlyAddedLocalPackageDirs.
Oh, another wrinkle here is that we don't actually know the name of
the package we're publishing when we create the PackageContext, so it
can't be an option.
Example of a failing self-test that now passes:
'packages with organizations'
There's no detail yet, but I'm going to add some. In the mean time,
you just get the total ms for "Selecting Package Versions...", and
if it runs a second time you'll get another report for "(Try 2)"!
With this change, `meteor update` with no arguments, in addition to
updating direct dependencies, updates patch versions of indirect
dependencies, so you will get your version 1.4.2 in the above example.
Background: As of the new solver, we already prefer patched versions
when selecting a version for a new indirect dependency. For example,
if 1.4.0 is the oldest version we could choose, we will take 1.4.1
instead if available. However, if 1.4.2 came out, there would never
be an occasion to take it, unless you explicitly typed
`meteor update the-indirect-dependency`. `meteor update` with no
args expands to `meteor update <all direct deps>`.
Also improve comments, tests, and code around CS.Input.
Verified manually that `meteor update asdf.` displays an error,
not a stack trace.
Include the offending name in all error messages (as we do for
invalid versions).
--breaking:
Allow packages in your project to be upgraded or downgraded
to versions that are not semver-compatible with the current
versions, if required to resolve package version conflicts.
Fix behavior so that packages you're updating count too.
In the return value, `name` has been changed to `package`,
and `vConstraint` is now `versionConstraint`.
`constraint.package` is better than `constraint.name`, where
`constraint` is a PackageConstraint. It's also more consistent
with functions like parsePackageAtVersion which return an object
like `{package, version}`.
`vConstraint` was too cryptic.
Changes were discussed with Glasser in a code review.
Troposphere does not call parseConstraint or work with constraint
objects, so it doesn't need to change.
This is a breaking change to the package-version-parser API (or one
method of it, at least), but it is considered an internal API so we
are not worrying too much about it.
Usually the project used for test-packages is a brand-new temporary
project. But you can also use --test-app-path, either for performance
reasons (to share the .meteor/local/isopacks cache between executions)
or because Cordova has issues with /tmp. Previous to this change,
though, test-packages would leave packages in .meteor/packages from a
previous execution, even if they were packages that we are no longer
testing.
Fixes#3446.
Summary:
Instead of expecting the child process to figure out where the
`.meteor/local` directory is, we now tell it explicitly via the
`METEOR_SHELL_DIR` environment variable.
Fixes#3437.
Test Plan:
Run `meteor shell` in a separate terminal and see that it still connects
to an app running from the same app directory.
Reviewers: glasser
Reviewed By: glasser
Differential Revision: https://phabricator.meteor.io/D11
This fixes a corner case where if you synced the catalog between the
creation of a release and the creation of its tool's build for your
platform, running `meteor --release R` would fail.
Fixes#3317.
This is a breaking change to package-version-parser.
A PackageConstraint used to look like this:
```
{ name: String,
constraintString: String,
constraints: [{version: String|null,
type: String}]}
```
Now it looks like this:
```
{ name: String,
constraintString: String,
vConstraint: {
raw: String,
alternatives: [{versionString: String|null,
type: String}]}}
```
Where (vConstraint instanceof VersionConstraint) and
(vConstraint.raw === constraintString).
This achieves several desirable changes at once.
* `constraint.constraints` for the disjuncts in “1.0.0||2.0.0”
was confusing. `alternatives` is better.
* Having a class for VersionConstraint will come in handy because
we can add methods to it, and we can use it in the constraint
solver to represent the problem statement.
* The names “vConstraint” and “versionString” are a little verbose,
but there really shouldn’t be a lot of code that dives into this
structure, and I really wanted to avoid anyone ever writing:
`constraint.constraint.alternatives[0].version`, and then wondering
what sort of object that was (not a parsed PackageVersion! we could
parse eagerly but that might be slow).
At least, not directly. When the tool wants to parse a string of the
form “package@version,” it now uses utils.parsePackageAtVersion.
This way, if I make a breaking change to PV.parseConstraint, I only have
to change a few call sites.
