Due to a type error, _checkUpToDatePreloaded always returned false, so
soft refresh never actually happened. Oops.
This might be (partially?) responsible for #3373.
Follow-up to b556e62262.
Priori to b556e62262, preserveLineNumbers always meant "in an app, not
linking multiple files into a single file" and noLineNumbers always
meant "this is an isopacket, ignoring line numbers for performance (but
still wanting source maps)".
b556e62262 made "noLineNumbers and no source map (eg, JS)" imply
preserveLineNumbers and not creating a source map for the nested
file. But that meant that in the isopacket case, the source map for the
linkered files didn't get you back to the pre-linker case.
This commit reverts to the previous behavior, where noLineNumbers + no
source map + !preserveLineNumbers still generates source maps
representing the linker transform itself.
I'm not sure if this is the complete description of the `fileOptions` parameter, but it would be helpful to see in the docs. Is `fileOptions` used by anything other than build plugins, so that I may update this PR?
When a source map is available, the line number annotations are now
computed from the source map. If no source map is available, but we are
planning to combine the file with other files in a package, we generate a
simple identity source map for the file and then annotate its line numbers
using that source map. This combination of techniques provides a tolerable
debugging experience in all browsers, even those that do not support
source maps.
The File.prototype._pathForSourceMap method was removed because it is no
longer used (self.servePath is better for source maps anyway, because it
includes parent directories, and the leading / character ensures that
source map paths will not be misinterpreted as relative paths).
self.declaredExports is always true since 0.9.0 (it comes from a _.pluck
in compiler.js) but test slices have their own package
name (local-test:*) so it's OK.
The static analysis is used to determine what "var"s need to be
automatically inserted by the linker at the package level. But for app
code, we never actually insert these vars, since apps run in "global
namespace" mode. So it's a waste of time to run the static analysis at
all.
The #1 goal is to not say, "Your packages are at
their latest compatible versions" whenever an
update has no effect. That isn't necessarily
true. `meteor update` with no arguments never
updates a major/minor of an indirect dependency,
for example. Also, you may have specified some
packages on the command line (though arguably
"your packages" could be interpreted to refer to
those packages).
In addition, `meteor update` with no arguments now
reports any direct or indirect dependencies that
aren't at their latest versions.
For example:
```
Your top-level dependencies are at their latest compatible versions.
Newer versions of the following indirect dependencies are available:
* aldeed:collection2 0.1.7 - 2.3.3 is available
To update one or more of these packages, pass their names to `meteor update`.
```
Sort of related to #4170.
This slightly alters the reg ex, because now there has to be at least
one character in name, whereas it could have been empty before. This
should be
irrelevant since the whole packageDot function only makes sense if name
is not empty.
We should be doing a lexicographical comparison of path components, rather
than including the `/` characters in the comparison, to match the order
given by the Unix `find` or `ls` commands.
Fixes#4300.
This fixes a crash when two architectures need to be downloaded
for the same package. It happens when building for non-host architecture
if packages have not been cached yet.
Crash happened because progress object got reused for another download request,
and progress objects are not supposed to be reused.
The comments immediately after this new code claimed that the "changes
we made were persisted to disk", but they weren't. So, if you had some
sort of build error that occured after the initializeCatalog stage (say,
invalid JS in a non-package.js file), when the runner reset the context,
it would lose the changes to
projectContext.projectConstraintsFile (.meteor/packages), and you'd end
up with no packages in the test runner app.
mongo now transitively uses webapp (because ddp-server does) so we can't
really make an app with mongo and no webapp. This is a bit of a shame
and when we refactor the mongo package we should fix this... but until
then, let's just remove the no-longer-necessary main function and be OK
with this test running a pointless web server.
However, turns out the previous commit doesn't really work --- making
webapp a strong dependency of ddp-server means that as soon as we load
mongo we'll load webapp in the tool which is bad. So move the mongodb
Npm module out of mongo, since that's all we need in the tool.
This change allows the tool to *read* .meteor/versions whether it uses
"@" or " " as a package/version separator. It does not change how
.meteor/versions is written out.
Background:
The convention in the new Version Solver is that "foo@1.2.3" means a
constraint, which is satisfied by "foo 1.2.4" but not "foo 1.2.2", which
are specific versions of a package. This convention avoids the same
confusion of .meteor/packages being a list of constraints while
.meteor/versions is conceptually a list of (package,version) pairs, even
though both look like package@version.
We'd like to replace "@" by " " in .meteor/versions from now on.
Unfortunately, even if the new tool can read old .meteor/versions files,
the old tool wouldn't be able to read the new style. If in some release
of Meteor, we start writing .meteor/versions that use spaces, you won't
be able to switch between newer and older releases of Meteor without
getting a hard error about a malformed versions file in your app.
What we can do, at least, is start letting the tool read the better
format now, and maybe in the future we can switch.
This change also makes parsePackageAtVersion stand alone, instead of
being defined in terms of parsePackageConstraint, which is nice.
This reverts commit 415c179310.
This commit was wrong. Instead of removing the `if` block
we should always be running the contents. Thanks @glasser
for noticing.
The fix to #3999 didn't work on newer Linux systems whose pgrep contains
the backwards-incompatible change
f12277c74d
to not include arguments.
Since the inspiration to use pgrep instead of 'ps ax' was to work around
an OS X bug, just avoid pgrep on Linux in the first place.
Fixes#4115.
This test had been somewhat flaky. It seems to be less flaky now.
Changes include:
- Trying to not send the client->server logging RPC if the client is
about to reload due to autoupdate
- Making sure that the client doesn't send anything at all until a
little bit after starting, in order to make the ordering of messages
between tool-printed and server-printed messages more predictable
Also updated from standard-app-packages to meteor-tool.
`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.
This restriction was originally in place because we did not know of a
use case for bare files on the server. The main use case for bare files
is putting pre-existing files in your app which expect top-level `var`s
to be "exported", which is common in browsers but not in Node.
However, there is a use case for this on the server: putting
pre-existing files that were originally written with clients in mind but
which function fine on the server into your server code. So we'll relax
the restriction.
Fixes#3681.
