In addition to package.json files with "babel" sections, BabelCompiler now
supports .babelrc files, though in both cases only the "presets" and
"plugins" fields are respected. If a .babelrc file is found, package.json
files are ignored.
Additional presets and plugins are now *prepended* to the original
babelOptions.{presets,plugins} lists, so that the custom plugins have a
chance to handle syntax differently than babel-preset-meteor would.
The inputFile.getPackageJson method has been replaced by a more general
method, inputFile.findControlFile.
Fixes#6351.
Switching immediately to module.import and module.export for package code
would make it difficult for package authors to use Meteor 1.3.3 to publish
packages that still work in apps using older versions of Meteor. There's
nothing wrong with compiling import/export statements to module.import and
module.export in application code, however, because apps only need to work
with one version of Meteor.
When the babel-compiler package is processing files, it will now read
their package.json files looking for a "babel" section with "presets" or
"plugins" fields. If found, these presets or plugins will be appended to
the existing babelOptions.presets or babelOptions.plugins arrays.
Note that no other Babel options are currently supported, and the
"babel-preset-meteor" preset cannot be removed, though additional presets
and/or plugins can be added to it. This is by design: Meteor cannot
support your configuration it uses babel-preset-meteor, at least.
The preset and/or plugin modules listed in package.json must be installed
locally somewhere such that the given file can import them. If they are
top-level identifiers, they will be prefixed with "babel-plugin-" or
"babel-preset-", the same as Babel does it. Otherwise they will be
required as-is, so that you can implement your own Babel plugins locally,
rather than always using plugins installed from npm.
See the included tests for a concrete example.
Fixes#6351.
These changes allow Package.registerCompiler-style compiler plugins to
extract package.json and npm package information at compile time from the
files that the plugin processes.
This information was accessible before, but it certainly wasn't easy to
obtain it. These convenience methods should satisfy the motivation behind
Even though @abernix set the circle.yml timeout to 1200 seconds, I'm still
seeing tests occasionally time out. This commit should prevent timeouts by
printing a "[ProgressDisplayFull keepalive]" message every five minutes,
if nothing else has been printed in the meantime.
Related: https://github.com/meteor/meteor/pull/7063
Saves 50MB from the extracted size of the dev_bundle/lib/node_modules
directory, previously 262MB. The entire dev bundle is 332MB extracted, for
perspective.
More importantly, since the `phantomjs` binary is not very compressible,
this change reduces the *compressed* size of the dev bundle from 71MB to
54MB, a 24% savings.
Closes#6905.
This never should have worked in Node v0.10.x, but with the v0.10.45
upgrade I stopped using npm@3 to build the Mac/Linux dev bundles (see
commit 916873ffe8f8ab6e922adfa68b8b8ab9c87db90d), which means we no longer
hoist the "process" npm package to the top level of the dev bundle
(dev_bundle/lib/node_modules/process), so now we're facing the expected
consequences of this mistake.
Recording process.versions allows us to be much more aggressive about
rebuilding binary dependencies whenever the version of Node/V8 might have
changed, even if the package was not just downloaded.
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.
Mainly because the dev bundle is so big, it took upwards on 5 mins (on my MBP w/ SSD) to copy the warehouse packages into the sandbox. AFAICT there is no reason not to symlink it if we can.
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.
