Update the default deploy server from deploy.meteor.com (which no longer
exists) to galaxy.meteor.com. However, if your app's DNS is already
pointed at Galaxy, automatically discover the deploy server's URL.
See meteor/amsterdam#305
"universe" was an old attempt to allow you to run various MDG
servers (Meteor Developer Accounts, the package server, an old version
of the Galaxy deploy server, etc) on localhost and configure the tool to
talk to it not via a bunch of environment variables but via a file
called "universe" at the root of your checkout. Nobody uses this (and
most of the URLs have environment variables for them anyway). Simplify
the code by removing this entirely.
Also remove some more dead code, and a test that claims it only runs if
you have universe set up.
Because longjohn was collecting frames across runs of self test in the loop, we were actually seeing frame lists that applied to more than one test.
This wasn't actually causing problems except in our frame parsing tests, but you can imagine that it would be quite unhelpful.
The `test` mode wasn't passing the proper proxyHost and proxyPort values to runAll. This changes the behaviour to work the same as the regular `run` mode and also adds tests for both modes to test the bindaddr (localAddress) is taking effect properly.
Fixesmeteor/meteor#6961
Importantly, the files can now differ with respect to their .lazy
properties, which fixes#6806 and related issues. Note that the files must
have different .targetPath values if they have the same .sourcePath.
This is a minor breaking change for code that relied on module.id being
based on the .sourcePath instead of the .targetPath.
This path can be specified by calling addJavaScript({ path: ... }), and
defaults to being identical to the .sourcePath if no options.path is
provided. The .targetPath may be different from the .sourcePath when a
compiler plugin calls addJavaScript multiple times for the same file,
using a different options.path each time, e.g. when a JSON configuration
file turns into multiple JS resources.
If we pass a file to ImportScanner#addInputFiles, and a module identifier
resolves to that file, it shouldn't matter if the file actually exists on
disk. A common example is a new file generated by a compiler plugin.
Fixes#6767.
This is essentially the same treatment we give to compilation errors in
lazy files processed by Package.registerCompiler-style plugins, which
fixed a similar issue: #5998. Here are the relevant commits:
be986fd709ce4fda3783
We can revisit this conversion if it turns out anyone really wants to use
@import rules in CSS files instead of using something like LESS.
Part of #6037.
This in important optimization for #6037, and it also fixes#6627, since
we are now registering watchSet dependencies on the contents of
node_modules directories.
The most notable change here is that we now treat files in app imports
directories as lazy even before we know whether the app is using modules.
This could be a breaking change for some 1.3 apps that do not use modules
but have imports directories containing eager .js files. That (very minor)
level of backwards incompatibility seems acceptable in the context of
upgrading to Meteor ~1.3, however.
