diff --git a/.circleci/config.yml b/.circleci/config.yml
index 9fb85d6669..a4e3e5944b 100644
--- a/.circleci/config.yml
+++ b/.circleci/config.yml
@@ -1,13 +1,5 @@
version: 2
-# These directories are cached across all builds, currently with no
-# hashing mechanism, but we should consider doing it off dev_bundle.
-meteor_cache_dirs: &meteor_cache_dirs
- paths:
- - "dev_bundle"
- - ".babel-cache"
- - ".meteor"
-
# A reusable "run" snippet which is ran before each test to setup the
# environment for user-limits, core-dumps, etc.
run_env_change: &run_env_change
@@ -17,13 +9,16 @@ run_env_change: &run_env_change
sudo mkdir -p /tmp/core_dumps
sudo chmod a+rwx /tmp/core_dumps
- # Make a place for JUnit tests to live.
- sudo mkdir -p /tmp/results/junit
- sudo chmod -R a+rwx /tmp/results/
+ # Bake the locale we expect into the image.
+ echo "en_US.UTF-8 UTF-8" | sudo tee /etc/locale.gen
+ sudo locale-gen
+
+ # The commands below don't work in Docker images, but might be worth
+ # reenabling if we switch back to machine:true instead of Docker.
# Set the pattern for core dumps, so we can find them.
- echo kernel.core_pattern="/tmp/core_dumps/core.%e.%p.%h.%t" | \
- sudo tee -a /etc/sysctl.conf
+ # echo kernel.core_pattern="/tmp/core_dumps/core.%e.%p.%h.%t" | \
+ # sudo tee -a /etc/sysctl.conf
# Note that since every "run" command starts its own shell, and I wasn't
# able to set this at a system wide level for all users, it's necessary to
@@ -31,11 +26,11 @@ run_env_change: &run_env_change
# output a core dump.
# Raise inotify user watches up higher.
- echo fs.inotify.max_user_watches=524288 | \
- sudo tee -a /etc/sysctl.conf
+ # echo fs.inotify.max_user_watches=524288 | \
+ # sudo tee -a /etc/sysctl.conf
# Reload sysctl so these are in effect.
- sudo sysctl -p
+ # sudo sysctl -p
# A reusable "run" snippet which enables the continued logging of memoryusage
# to a file on disk which can be saved to build artifacts for later analysis.
@@ -46,7 +41,8 @@ run_log_mem_use: &run_log_mem_use
# Log memory usage throughout entire build.
MEMUSELOG=/tmp/memuse.txt /bin/bash -c '\
while true; do\
- ps -u $USER eo pid,%cpu,%mem,rss:10,vsz:10,args:20 --sort=-%mem >> $MEMUSELOG; \
+ ps -e -o user,%cpu,%mem,rss:10,vsz:10,command:20 \
+ --sort=-%mem >> $MEMUSELOG; \
echo "----------" >> $MEMUSELOG; \
sleep 1; \
done'
@@ -64,14 +60,17 @@ run_save_node_bin: &run_save_node_bin
# This environment is set to every job (and the initial build).
build_machine_environment: &build_machine_environment
# Specify that we want an actual machine (ala Circle 1.0), not a Docker image.
- machine: true
+ docker:
+ - image: meteor/circleci
environment:
# This multiplier scales the waitSecs for selftests.
TIMEOUT_SCALE_FACTOR: 8
+ # Retry failed tests additional times.
+ METEOR_SELF_TEST_RETRIES: 2
+
# These, mostly overlapping, flags ensure that CircleCI is as pretty as
# possible for a non-interactive environment. See also: --headless.
- EMACS: t
METEOR_HEADLESS: true
METEOR_PRETTY_OUTPUT: 0
@@ -80,26 +79,23 @@ build_machine_environment: &build_machine_environment
METEOR_SAVE_TMPDIRS: 1
# Skip these tests on every test run.
- # For readability, this is a regex wrapped across multiple lines in quotes.
- SELF_TEST_EXCLUDE: "\
- ^old cli tests|\
- ^minifiers can't register non-js|\
- ^minifiers: apps can't use|\
- ^compiler plugins - addAssets\
- "
+ # If needed, for readability this should be a regex wrapped across
+ # multiple lines in quotes.
+ SELF_TEST_EXCLUDE: "add debugOnly and prodOnly packages"
+
# These will be evaled before each command.
PRE_TEST_COMMANDS: |-
ulimit -c unlimited; # Set core dump size as Ubuntu 14.04 lacks prlimit.
- ulimit -n 4096; # CircleCI default is soft 1024, hard 4096. Take it all.
-
- # Enable the Garbage Collection `gc` object to be exposed so we can try
- # to our own, hopefully more graceful, technique.
- TOOL_NODE_FLAGS: --expose-gc
+ ulimit -a # Display all ulimit settings for transparency.
# This is only to make Meteor self-test not remind us that we can set
# this argument for self-tests.
SELF_TEST_TOOL_NODE_FLAGS: " "
+ # Variables for load-balancing
+ NUM_GROUPS: 11
+ RUNNING_AVG_LENGTH: 5
+
jobs:
Get Ready:
<<: *build_machine_environment
@@ -114,7 +110,39 @@ jobs:
name: Git Submodules.
command: (git submodule sync && git submodule update --init --recursive) || (rm -fr .git/config .git/modules && git submodule deinit -f . && git submodule update --init --recursive)
- restore_cache:
- key: meteor-cache
+ keys:
+ - v1-dev-bundle-cache-{{ checksum "meteor" }}
+ - v1-dev-bundle-cache-
+ - run:
+ name: Combine NPM Shrinkwrap Files
+ command: |
+ for d in packages/*/.npm/package; do cat $d/npm-shrinkwrap.json >> shrinkwraps.txt; done
+ for d in packages/*/.npm/plugin/*; do cat $d/npm-shrinkwrap.json >> shrinkwraps.txt; done
+ - restore_cache:
+ keys:
+ - package-npm-deps-cache-group1-v1-{{ checksum "shrinkwraps.txt" }}
+ - package-npm-deps-cache-group1-v1-
+ - restore_cache:
+ keys:
+ - package-npm-deps-cache-group2-v3-{{ checksum "shrinkwraps.txt" }}
+ - package-npm-deps-cache-group2-v3-
+ - restore_cache:
+ keys:
+ - v2-other-deps-cache-{{ .Branch }}-{{ .Revision }}
+ - v2-other-deps-cache-{{ .Branch }}-
+ - restore_cache:
+ keys:
+ - v1-test-groups-{{ .Branch }}
+ - v1-test-groups-
+ - run:
+ name: Create Test Results Directory
+ command: |
+ sudo mkdir -p ./tmp/results/junit
+ sudo chmod a+rwx ./tmp/results/junit
+ # Clear dev_bundle/.npm to ensure consistent test runs.
+ - run:
+ name: Clear npm cache
+ command: ./meteor npm cache clear --force
- run:
name: Get Ready
command: |
@@ -122,15 +150,6 @@ jobs:
./meteor --get-ready
# shouldn't take longer than 20 minutes
no_output_timeout: 20m
- # Clear dev_bundle/.npm to ensure consistent test runs.
- - run:
- name: Clear npm cache
- command: ./meteor npm cache clear --force
- # Since PhantomJS has been removed from dev_bundle/lib/node_modules
- # (#6905), but self-test still needs it, install it now.
- - run:
- name: Test Prereqs
- command: ./meteor npm install -g phantomjs-prebuilt browserstack-webdriver
- run:
<<: *run_save_node_bin
- persist_to_workspace:
@@ -141,16 +160,7 @@ jobs:
- store_artifacts:
path: /tmp/memuse.txt
- save_caches:
- <<: *build_machine_environment
- steps:
- - attach_workspace:
- at: .
- - save_cache:
- key: meteor-cache
- <<: *meteor_cache_dirs
-
- Group 0:
+ Isolated Tests:
<<: *build_machine_environment
steps:
- run:
@@ -163,30 +173,38 @@ jobs:
name: "Print environment"
command: printenv
- run:
- name: "Running warehouse self-tests"
+ name: "Running self-test ('package-tests: add debugOnly and prodOnly packages')"
command: |
eval $PRE_TEST_COMMANDS;
./meteor self-test \
+ 'add debugOnly and prodOnly packages' \
+ --retries ${METEOR_SELF_TEST_RETRIES} \
+ --headless \
+ --phantom
+ no_output_timeout: 20m
+ - run:
+ name: "Running self-test (Custom Warehouse Tests)"
+ command: |
+ eval $PRE_TEST_COMMANDS;
+ ./meteor self-test \
+ --retries ${METEOR_SELF_TEST_RETRIES} \
--exclude "${SELF_TEST_EXCLUDE}" \
--headless \
- --junit /tmp/results/junit/0.xml \
+ --phantom \
--with-tag "custom-warehouse"
no_output_timeout: 20m
- run:
<<: *run_save_node_bin
- - save_cache:
- key: meteor-cache
- <<: *meteor_cache_dirs
- store_test_results:
- path: /tmp/results
+ path: ./tmp/results
- store_artifacts:
- path: /tmp/results
+ path: ./tmp/results
- store_artifacts:
path: /tmp/core_dumps
- store_artifacts:
path: /tmp/memuse.txt
- Group 1:
+ Test Group 0:
<<: *build_machine_environment
steps:
- run:
@@ -199,31 +217,35 @@ jobs:
name: "Print environment"
command: printenv
- run:
- name: "Running self-test (1): A-Com"
+ name: "Running self-test (Test Group 0)"
command: |
+ if [ -f ./tmp/test-groups/0.txt ]; then TEST_GROUP=$(<./tmp/test-groups/0.txt); else TEST_GROUP='^[a-b]|^c[a-n]|^co[a-l]|^comm'; fi
+ echo $TEST_GROUP;
eval $PRE_TEST_COMMANDS;
./meteor self-test \
+ "$TEST_GROUP" \
+ --retries ${METEOR_SELF_TEST_RETRIES} \
--exclude "${SELF_TEST_EXCLUDE}" \
--headless \
- --junit /tmp/results/junit/1.xml \
- --file '^[a-b]|^c[a-n]|^co[a-l]|^compiler-plugins' \
+ --phantom \
+ --junit ./tmp/results/junit/0.xml \
--without-tag "custom-warehouse"
no_output_timeout: 20m
- run:
<<: *run_save_node_bin
- - save_cache:
- key: meteor-cache
- <<: *meteor_cache_dirs
- store_test_results:
- path: /tmp/results
+ path: ./tmp/results
+ - persist_to_workspace:
+ root: .
+ paths: ./tmp/results/junit
- store_artifacts:
- path: /tmp/results
+ path: ./tmp/results
- store_artifacts:
path: /tmp/core_dumps
- store_artifacts:
path: /tmp/memuse.txt
- Group 2:
+ Test Group 1:
<<: *build_machine_environment
steps:
- run:
@@ -236,31 +258,35 @@ jobs:
name: "Print environment"
command: printenv
- run:
- name: "Running self-test (2): Con-K"
+ name: "Running self-test (Test Group 1)"
command: |
+ if [ -f ./tmp/test-groups/1.txt ]; then TEST_GROUP=$(<./tmp/test-groups/1.txt); elif [ -f ./tmp/test-groups/0.txt ]; then TEST_GROUP=XXXXX; else TEST_GROUP='^com[n-z]'; fi
+ echo $TEST_GROUP;
eval $PRE_TEST_COMMANDS;
./meteor self-test \
+ "$TEST_GROUP" \
+ --retries ${METEOR_SELF_TEST_RETRIES} \
--exclude "${SELF_TEST_EXCLUDE}" \
--headless \
- --junit /tmp/results/junit/2.xml \
- --file "^co[n-z]|^c[p-z]|^[d-k]" \
+ --phantom \
+ --junit ./tmp/results/junit/1.xml \
--without-tag "custom-warehouse"
no_output_timeout: 20m
- run:
<<: *run_save_node_bin
- - save_cache:
- key: meteor-cache
- <<: *meteor_cache_dirs
- store_test_results:
- path: /tmp/results
+ path: ./tmp/results
+ - persist_to_workspace:
+ root: .
+ paths: ./tmp/results/junit
- store_artifacts:
- path: /tmp/results
+ path: ./tmp/results
- store_artifacts:
path: /tmp/core_dumps
- store_artifacts:
path: /tmp/memuse.txt
- Group 3:
+ Test Group 2:
<<: *build_machine_environment
steps:
- run:
@@ -273,31 +299,35 @@ jobs:
name: "Print environment"
command: printenv
- run:
- name: "Running self-test (3): L-O"
+ name: "Running self-test (Test Group 2)"
command: |
+ if [ -f ./tmp/test-groups/2.txt ]; then TEST_GROUP=$(<./tmp/test-groups/2.txt); elif [ -f ./tmp/test-groups/0.txt ]; then TEST_GROUP=XXXXX; else TEST_GROUP='^co[n-z]'; fi
+ echo $TEST_GROUP;
eval $PRE_TEST_COMMANDS;
./meteor self-test \
+ "$TEST_GROUP" \
+ --retries ${METEOR_SELF_TEST_RETRIES} \
--exclude "${SELF_TEST_EXCLUDE}" \
--headless \
- --junit /tmp/results/junit/3.xml \
- --file '^[l-o]' \
+ --phantom \
+ --junit ./tmp/results/junit/2.xml \
--without-tag "custom-warehouse"
no_output_timeout: 20m
- run:
<<: *run_save_node_bin
- - save_cache:
- key: meteor-cache
- <<: *meteor_cache_dirs
- store_test_results:
- path: /tmp/results
+ path: ./tmp/results
+ - persist_to_workspace:
+ root: .
+ paths: ./tmp/results/junit
- store_artifacts:
- path: /tmp/results
+ path: ./tmp/results
- store_artifacts:
path: /tmp/core_dumps
- store_artifacts:
path: /tmp/memuse.txt
- Group 4:
+ Test Group 3:
<<: *build_machine_environment
steps:
- run:
@@ -310,68 +340,35 @@ jobs:
name: "Print environment"
command: printenv
- run:
- name: "Running self-test (4): P"
- command: |
- eval $PRE_TEST_COMMANDS;
- ./meteor self-test \
- --exclude "${SELF_TEST_EXCLUDE}" \
- --headless \
- --junit /tmp/results/junit/4.xml \
- --file '^p' \
- --without-tag "custom-warehouse"
- no_output_timeout: 20m
- - run:
- <<: *run_save_node_bin
- - save_cache:
- key: meteor-cache
- <<: *meteor_cache_dirs
- - store_test_results:
- path: /tmp/results
- - store_artifacts:
- path: /tmp/results
- - store_artifacts:
- path: /tmp/core_dumps
- - store_artifacts:
- path: /tmp/memuse.txt
-
- Group 5:
- <<: *build_machine_environment
- steps:
- - run:
- <<: *run_log_mem_use
- - run:
- <<: *run_env_change
- - attach_workspace:
- at: .
- - run:
- name: "Print environment"
- command: printenv
- - run:
- name: "Running self-test (5): Run"
+ name: "Running self-test (Test Group 3)"
command: |
+ if [ -f ./tmp/test-groups/3.txt ]; then TEST_GROUP=$(<./tmp/test-groups/3.txt); elif [ -f ./tmp/test-groups/0.txt ]; then TEST_GROUP=XXXXX; else TEST_GROUP='^c[p-z]|^[d-g]|^h[a-e]'; fi
+ echo $TEST_GROUP;
eval $PRE_TEST_COMMANDS;
./meteor self-test \
+ "$TEST_GROUP" \
+ --retries ${METEOR_SELF_TEST_RETRIES} \
--exclude "${SELF_TEST_EXCLUDE}" \
--headless \
- --junit /tmp/results/junit/5.xml \
- --file '^run' \
+ --phantom \
+ --junit ./tmp/results/junit/3.xml \
--without-tag "custom-warehouse"
no_output_timeout: 20m
- run:
<<: *run_save_node_bin
- - save_cache:
- key: meteor-cache
- <<: *meteor_cache_dirs
- store_test_results:
- path: /tmp/results
+ path: ./tmp/results
+ - persist_to_workspace:
+ root: .
+ paths: ./tmp/results/junit
- store_artifacts:
- path: /tmp/results
+ path: ./tmp/results
- store_artifacts:
path: /tmp/core_dumps
- store_artifacts:
path: /tmp/memuse.txt
- Group 6:
+ Test Group 4:
<<: *build_machine_environment
steps:
- run:
@@ -384,31 +381,35 @@ jobs:
name: "Print environment"
command: printenv
- run:
- name: "Running self-test (6): R-S"
+ name: "Running self-test (Test Group 4)"
command: |
+ if [ -f ./tmp/test-groups/4.txt ]; then TEST_GROUP=$(<./tmp/test-groups/4.txt); elif [ -f ./tmp/test-groups/0.txt ]; then TEST_GROUP=XXXXX; else TEST_GROUP='^h[f-z]|^[i-l]'; fi
+ echo $TEST_GROUP;
eval $PRE_TEST_COMMANDS;
./meteor self-test \
+ "$TEST_GROUP" \
+ --retries ${METEOR_SELF_TEST_RETRIES} \
--exclude "${SELF_TEST_EXCLUDE}" \
--headless \
- --junit /tmp/results/junit/6.xml \
- --file '^r(?!un)|^s' \
+ --phantom \
+ --junit ./tmp/results/junit/4.xml \
--without-tag "custom-warehouse"
no_output_timeout: 20m
- run:
<<: *run_save_node_bin
- - save_cache:
- key: meteor-cache
- <<: *meteor_cache_dirs
- store_test_results:
- path: /tmp/results
+ path: ./tmp/results
+ - persist_to_workspace:
+ root: .
+ paths: ./tmp/results/junit
- store_artifacts:
- path: /tmp/results
+ path: ./tmp/results
- store_artifacts:
path: /tmp/core_dumps
- store_artifacts:
path: /tmp/memuse.txt
- Group 7:
+ Test Group 5:
<<: *build_machine_environment
steps:
- run:
@@ -421,56 +422,406 @@ jobs:
name: "Print environment"
command: printenv
- run:
- name: "Running self-test (7): Sp-Z"
+ name: "Running self-test (Test Group 5)"
command: |
+ if [ -f ./tmp/test-groups/5.txt ]; then TEST_GROUP=$(<./tmp/test-groups/5.txt); elif [ -f ./tmp/test-groups/0.txt ]; then TEST_GROUP=XXXXX; else TEST_GROUP='^m[a-n]|^mo[a-d]'; fi
+ echo $TEST_GROUP;
eval $PRE_TEST_COMMANDS;
./meteor self-test \
+ "$TEST_GROUP" \
+ --retries ${METEOR_SELF_TEST_RETRIES} \
--exclude "${SELF_TEST_EXCLUDE}" \
--headless \
- --junit /tmp/results/junit/7.xml \
- --file '^[t-z]|^command-line' \
+ --phantom \
+ --junit ./tmp/results/junit/5.xml \
--without-tag "custom-warehouse"
no_output_timeout: 20m
- run:
<<: *run_save_node_bin
- - save_cache:
- key: meteor-cache
- <<: *meteor_cache_dirs
- store_test_results:
- path: /tmp/results
+ path: ./tmp/results
+ - persist_to_workspace:
+ root: .
+ paths: ./tmp/results/junit
- store_artifacts:
- path: /tmp/results
+ path: ./tmp/results
- store_artifacts:
path: /tmp/core_dumps
- store_artifacts:
path: /tmp/memuse.txt
+ Test Group 6:
+ <<: *build_machine_environment
+ steps:
+ - run:
+ <<: *run_log_mem_use
+ - run:
+ <<: *run_env_change
+ - attach_workspace:
+ at: .
+ - run:
+ name: "Print environment"
+ command: printenv
+ - run:
+ name: "Running self-test (Test Group 6)"
+ command: |
+ if [ -f ./tmp/test-groups/6.txt ]; then TEST_GROUP=$(<./tmp/test-groups/6.txt); elif [ -f ./tmp/test-groups/0.txt ]; then TEST_GROUP=XXXXX; else TEST_GROUP='^mo[e-z]|^m[p-z]|^[n-o]'; fi
+ echo $TEST_GROUP;
+ eval $PRE_TEST_COMMANDS;
+ ./meteor self-test \
+ "$TEST_GROUP" \
+ --retries ${METEOR_SELF_TEST_RETRIES} \
+ --exclude "${SELF_TEST_EXCLUDE}" \
+ --headless \
+ --phantom \
+ --junit ./tmp/results/junit/6.xml \
+ --without-tag "custom-warehouse"
+ no_output_timeout: 20m
+ - run:
+ <<: *run_save_node_bin
+ - store_test_results:
+ path: ./tmp/results
+ - persist_to_workspace:
+ root: .
+ paths: ./tmp/results/junit
+ - store_artifacts:
+ path: ./tmp/results
+ - store_artifacts:
+ path: /tmp/core_dumps
+ - store_artifacts:
+ path: /tmp/memuse.txt
+
+ Test Group 7:
+ <<: *build_machine_environment
+ steps:
+ - run:
+ <<: *run_log_mem_use
+ - run:
+ <<: *run_env_change
+ - attach_workspace:
+ at: .
+ - run:
+ name: "Print environment"
+ command: printenv
+ - run:
+ name: "Running self-test (Test Group 7)"
+ command: |
+ if [ -f ./tmp/test-groups/7.txt ]; then TEST_GROUP=$(<./tmp/test-groups/7.txt); elif [ -f ./tmp/test-groups/0.txt ]; then TEST_GROUP=XXXXX; else TEST_GROUP='^[p-q]|^r[a-e]'; fi
+ echo $TEST_GROUP;
+ eval $PRE_TEST_COMMANDS;
+ ./meteor self-test \
+ "$TEST_GROUP" \
+ --retries ${METEOR_SELF_TEST_RETRIES} \
+ --exclude "${SELF_TEST_EXCLUDE}" \
+ --headless \
+ --phantom \
+ --junit ./tmp/results/junit/7.xml \
+ --without-tag "custom-warehouse"
+ no_output_timeout: 20m
+ - run:
+ <<: *run_save_node_bin
+ - store_test_results:
+ path: ./tmp/results
+ - persist_to_workspace:
+ root: .
+ paths: ./tmp/results/junit
+ - store_artifacts:
+ path: ./tmp/results
+ - store_artifacts:
+ path: /tmp/core_dumps
+ - store_artifacts:
+ path: /tmp/memuse.txt
+
+ Test Group 8:
+ <<: *build_machine_environment
+ steps:
+ - run:
+ <<: *run_log_mem_use
+ - run:
+ <<: *run_env_change
+ - attach_workspace:
+ at: .
+ - run:
+ name: "Print environment"
+ command: printenv
+ - run:
+ name: "Running self-test (Test Group 8)"
+ command: |
+ if [ -f ./tmp/test-groups/8.txt ]; then TEST_GROUP=$(<./tmp/test-groups/8.txt); elif [ -f ./tmp/test-groups/0.txt ]; then TEST_GROUP=XXXXX; else TEST_GROUP='^r[f-z]'; fi
+ echo $TEST_GROUP;
+ eval $PRE_TEST_COMMANDS;
+ ./meteor self-test \
+ "$TEST_GROUP" \
+ --retries ${METEOR_SELF_TEST_RETRIES} \
+ --exclude "${SELF_TEST_EXCLUDE}" \
+ --headless \
+ --phantom \
+ --junit ./tmp/results/junit/8.xml \
+ --without-tag "custom-warehouse"
+ no_output_timeout: 20m
+ - run:
+ <<: *run_save_node_bin
+ - store_test_results:
+ path: ./tmp/results
+ - persist_to_workspace:
+ root: .
+ paths: ./tmp/results/junit
+ - store_artifacts:
+ path: ./tmp/results
+ - store_artifacts:
+ path: /tmp/core_dumps
+ - store_artifacts:
+ path: /tmp/memuse.txt
+
+ Test Group 9:
+ <<: *build_machine_environment
+ steps:
+ - run:
+ <<: *run_log_mem_use
+ - run:
+ <<: *run_env_change
+ - attach_workspace:
+ at: .
+ - run:
+ name: "Print environment"
+ command: printenv
+ - run:
+ name: "Running self-test (Test Group 9)"
+ command: |
+ if [ -f ./tmp/test-groups/9.txt ]; then TEST_GROUP=$(<./tmp/test-groups/9.txt); elif [ -f ./tmp/test-groups/0.txt ]; then TEST_GROUP=XXXXX; else TEST_GROUP='^s'; fi
+ echo $TEST_GROUP;
+ eval $PRE_TEST_COMMANDS;
+ ./meteor self-test \
+ "$TEST_GROUP" \
+ --retries ${METEOR_SELF_TEST_RETRIES} \
+ --exclude "${SELF_TEST_EXCLUDE}" \
+ --headless \
+ --phantom \
+ --junit ./tmp/results/junit/9.xml \
+ --without-tag "custom-warehouse"
+ no_output_timeout: 20m
+ - run:
+ <<: *run_save_node_bin
+ - store_test_results:
+ path: ./tmp/results
+ - persist_to_workspace:
+ root: .
+ paths: ./tmp/results/junit
+ - store_artifacts:
+ path: ./tmp/results
+ - store_artifacts:
+ path: /tmp/core_dumps
+ - store_artifacts:
+ path: /tmp/memuse.txt
+
+ Test Group 10:
+ <<: *build_machine_environment
+ steps:
+ - run:
+ <<: *run_log_mem_use
+ - run:
+ <<: *run_env_change
+ - attach_workspace:
+ at: .
+ - run:
+ name: "Print environment"
+ command: printenv
+ - run:
+ name: "Running self-test (Test Group 10)"
+ command: |
+ if [ -f ./tmp/test-groups/10.txt ]; then TEST_GROUP=$(<./tmp/test-groups/10.txt); elif [ -f ./tmp/test-groups/0.txt ]; then TEST_GROUP=XXXXX; else TEST_GROUP='^[t-z]'; fi
+ echo $TEST_GROUP;
+ eval $PRE_TEST_COMMANDS;
+ ./meteor self-test \
+ "$TEST_GROUP" \
+ --retries ${METEOR_SELF_TEST_RETRIES} \
+ --exclude "${SELF_TEST_EXCLUDE}" \
+ --headless \
+ --phantom \
+ --junit ./tmp/results/junit/10.xml \
+ --without-tag "custom-warehouse"
+ no_output_timeout: 20m
+ - run:
+ <<: *run_save_node_bin
+ - store_test_results:
+ path: ./tmp/results
+ - persist_to_workspace:
+ root: .
+ paths: ./tmp/results/junit
+ - store_artifacts:
+ path: ./tmp/results
+ - store_artifacts:
+ path: /tmp/core_dumps
+ - store_artifacts:
+ path: /tmp/memuse.txt
+
+ # Test the JSDoc declarations which live within this codebase against the
+ # Meteor Docs (https://github.com/meteor/docs) repository, where they'll
+ # eventually be consumed. This test aims to provide an early warning of
+ # potentially breaking changes, so they aren't discovered when the docs are
+ # next updated, which generally occurs during major Meteor version releases
+ # (for example, 1.4 to 1.5, 1.5 to 1.6).
+ Docs:
+ docker:
+ # This Node version should match that in the meteor/docs CircleCI config.
+ - image: circleci/node:8
+ environment:
+ CHECKOUT_METEOR_DOCS: /home/circleci/test_docs
+ steps:
+ - run:
+ name: Cloning "meteor/docs" Repository's "master" branch
+ command: |
+ git clone https://github.com/meteor/docs.git ${CHECKOUT_METEOR_DOCS}
+ # The "docs" repository normally brings in the Meteor code as a Git
+ # submodule checked out into the "code" directory. As the goal of this
+ # test is to run it against the _current_ repository's code, we'll move
+ # the "code" directory out of the way and move the checkout (of meteor)
+ # into that directory, rather than the default $CIRCLE_WORKING_DIRECTORY.
+ - checkout
+ - run:
+ name: Move Meteor checkout into docs repository's "code" directory
+ command: |
+ rmdir "${CHECKOUT_METEOR_DOCS}/code"
+ # $CIRCLE_WORKING_DIRECTORY uses a tilde, so expand it to $HOME.
+ mv "${CIRCLE_WORKING_DIRECTORY/#\~/$HOME}" \
+ "${CHECKOUT_METEOR_DOCS}/code"
+ # Run almost the same steps the meteor/docs repository runs, minus deploy.
+ - run:
+ name: Generating Meteor documentation for JSDoc testing
+ command: |
+ cd ${CHECKOUT_METEOR_DOCS}
+ npm install
+ npm test
+
+ Clean Up:
+ <<: *build_machine_environment
+ steps:
+ - attach_workspace:
+ at: .
+ - run:
+ name: Create Test Groups Directory
+ command: |
+ sudo mkdir -p ./tmp/test-groups
+ sudo chmod a+rwx ./tmp/test-groups
+ - run:
+ name: Calculate Balanced Test Groups
+ command: |
+ npm install --prefix ./scripts/test-balancer
+ npm start --prefix ./scripts/test-balancer --num-groups ${NUM_GROUPS} --running-avg-length ${RUNNING_AVG_LENGTH}
+ - save_cache:
+ key: v1-test-groups-{{ .Branch }}-{{ .BuildNum }}
+ paths:
+ - ./tmp/test-groups
+ when: on_success
+ - save_cache:
+ key: v1-dev-bundle-cache-{{ checksum "meteor" }}
+ paths:
+ - "dev_bundle"
+ # The package npm dependencies are split into two caches to avoid an AWS
+ # `MetadataTooLarge` error that consistently appears if we put all of
+ # these folders in the same cache
+ - save_cache:
+ key: package-npm-deps-cache-group1-v1-{{ checksum "shrinkwraps.txt" }}
+ paths:
+ - packages/meteor/.npm/package/node_modules
+ - packages/modules-runtime/.npm/package/node_modules
+ - packages/modules/.npm/package/node_modules
+ - packages/ecmascript-runtime-server/.npm/package/node_modules
+ - packages/promise/.npm/package/node_modules
+ - packages/babel-compiler/.npm/package/node_modules
+ - packages/babel-runtime/.npm/package/node_modules
+ - packages/http/.npm/package/node_modules
+ - packages/socket-stream-client/.npm/package/node_modules
+ - packages/ddp-client/.npm/package/node_modules
+ - packages/npm-mongo/.npm/package/node_modules
+ - packages/package-version-parser/.npm/package/node_modules
+ - packages/boilerplate-generator/.npm/package/node_modules
+ - save_cache:
+ key: package-npm-deps-cache-group2-v3-{{ checksum "shrinkwraps.txt" }}
+ paths:
+ - packages/xmlbuilder/.npm/package/node_modules
+ - packages/logging/.npm/package/node_modules
+ - packages/webapp/.npm/package/node_modules
+ - packages/ddp-server/.npm/package/node_modules
+ - packages/mongo/.npm/package/node_modules
+ - packages/npm-bcrypt/.npm/package/node_modules
+ - packages/email/.npm/package/node_modules
+ - packages/caching-compiler/.npm/package/node_modules
+ - packages/less/.npm/plugin/compileLessBatch/node_modules
+ - packages/non-core/blaze/packages/spacebars-compiler/.npm/package/node_modules
+ - packages/boilerplate-generator-tests/.npm/package/node_modules
+ - packages/non-core/bundle-visualizer/.npm/package/node_modules
+ - packages/d3-hierarchy/.npm/package/node_modules
+ - packages/non-core/coffeescript-compiler/.npm/package/node_modules
+ - packages/server-render/.npm/package/node_modules
+ - packages/es5-shim/.npm/package/node_modules
+ - packages/force-ssl-common/.npm/package/node_modules
+ - packages/jshint/.npm/plugin/lintJshint/node_modules
+ - packages/minifier-css/.npm/package/node_modules
+ - packages/minifier-js/.npm/package/node_modules
+ - packages/standard-minifier-css/.npm/plugin/minifyStdCSS/node_modules
+ - packages/inter-process-messaging/.npm/package/node_modules
+ - packages/fetch/.npm/package/node_modules
+ - packages/non-core/mongo-decimal/.npm/package/node_modules
+ - save_cache:
+ key: v2-other-deps-cache-{{ .Branch }}-{{ .Revision }}
+ paths:
+ - ".babel-cache"
+ - ".meteor"
+
workflows:
version: 2
Build and Test:
jobs:
+ - Docs
- Get Ready
- - Group 0:
+ - Isolated Tests:
requires:
- Get Ready
- - Group 1:
+ - Test Group 0:
requires:
- Get Ready
- - Group 2:
+ - Test Group 1:
requires:
- Get Ready
- - Group 3:
+ - Test Group 2:
requires:
- Get Ready
- - Group 4:
+ - Test Group 3:
requires:
- Get Ready
- - Group 5:
+ - Test Group 4:
requires:
- Get Ready
- - Group 6:
+ - Test Group 5:
requires:
- Get Ready
- - Group 7:
+ - Test Group 6:
requires:
- Get Ready
+ - Test Group 7:
+ requires:
+ - Get Ready
+ - Test Group 8:
+ requires:
+ - Get Ready
+ - Test Group 9:
+ requires:
+ - Get Ready
+ - Test Group 10:
+ requires:
+ - Get Ready
+ - Clean Up:
+ requires:
+ - Isolated Tests
+ - Test Group 0
+ - Test Group 1
+ - Test Group 2
+ - Test Group 3
+ - Test Group 4
+ - Test Group 5
+ - Test Group 6
+ - Test Group 7
+ - Test Group 8
+ - Test Group 9
+ - Test Group 10
diff --git a/.github/ISSUE_TEMPLATE.md b/.github/ISSUE_TEMPLATE.md
index f436b53cbc..758bfb59fe 100644
--- a/.github/ISSUE_TEMPLATE.md
+++ b/.github/ISSUE_TEMPLATE.md
@@ -12,9 +12,9 @@ first and read the instructions for filing a bug report:
https://github.com/meteor/meteor/blob/devel/CONTRIBUTING.md#reporting-a-bug-in-meteor
### This bug report should include:
-- [ ] A descriptive title
+- [ ] A short, but descriptive title. The title doesn't need "Meteor" in it.
- [ ] The version of Meteor showing the problem.
-- [ ] The last version of Meteor where the problem did _not_ occur (if applicable)
+- [ ] The last version of Meteor where the problem did _not_ occur, if applicable.
- [ ] The operating system you're running Meteor on.
- [ ] The expected behavior.
- [ ] The actual behavior.
diff --git a/.travis.yml b/.travis.yml
index e943bf20c2..0cf166baac 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -1,11 +1,11 @@
language: node_js
node_js:
- - "4.0"
+ - "8.11.1"
cache:
directories:
- ".meteor"
- ".babel-cache"
-script: TEST_PACKAGES_EXCLUDE="less" ./packages/test-in-console/run.sh
+script: TEST_PACKAGES_EXCLUDE="less" phantom=false ./packages/test-in-console/run.sh
sudo: false
env:
- CXX=g++-4.8
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 33ca5cfa03..37c9d5b073 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -11,7 +11,7 @@ Before we jump into detailed guidelines for opening and triaging issues and subm
There are many ways to contribute to the Meteor Project. Here’s a list of technical contributions with increasing levels of involvement and required knowledge of Meteor’s code and operations.
- [Reporting a bug](CONTRIBUTING.md#reporting-a-bug-in-meteor)
- [Triaging issues](ISSUE_TRIAGE.md)
-- [Contributing to documentation](https://github.com/meteor/docs/blob/master/CONTRIBUTING.md)
+- [Contributing to documentation](CONTRIBUTING.md#documentation)
- [Finding work](CONTRIBUTING.md#finding-work)
- [Submitting pull requests](CONTRIBUTING.md#making-changes-to-meteor-core)
- [Reviewing pull requests](CONTRIBUTING.md#reviewer)
@@ -29,6 +29,8 @@ Issues which *also* have the `confirmed` label ([bugs](https://github.com/meteor
Any issue which does not have the `confirmed` label still requires discussion on implementation details but input and positive commentary is welcome! Any pull request opened on an issue which is not `confirmed` is still welcome, however the pull-request is more likely to be sent back for reworking than a `confirmed` issue. If in doubt about the best way to implement something, please create additional conversation on the issue.
+Please note that `pull-requests-encouraged` issues with low activity will often be closed without being implemented. These issues are tagged with an additional [`not-implemented`](https://github.com/meteor/meteor/issues?utf8=✓&q=label%3Apull-requests-encouraged+label%3Anot-implemented) label, and can still be considered good candidates to work on. If you're interested in working on a closed and `not-implemented` issue, please let us know by posting on that issue.
+
### Project roles
We’ve just begun to create more defined project roles for Meteor. Here are descriptions of the existing project roles, along with the current contributors taking on those roles today.
@@ -168,7 +170,7 @@ A great way to contribute to Meteor is by helping keep the issues in the reposit
## Documentation
-If you'd like to contribution to Meteor's documentation, head over to https://github.com/meteor/docs and create issues or pull requests there.
+If you'd like to contribute to Meteor's documentation, head over to https://github.com/meteor/docs and create issues or pull requests there.
## Blaze
diff --git a/History.md b/History.md
index 70304ff5e2..53e80785fc 100644
--- a/History.md
+++ b/History.md
@@ -1,14 +1,1103 @@
## v.NEXT
-* [`cordova-lib`](https://github.com/apache/cordova-cli) has been updated to
- version 7.1.0, [`cordova-android`](https://github.com/apache/cordova-android/)
- has been updated to version 6.3.0, and [`cordova-ios`](https://github.com/apache/cordova-ios/)
- has been updated to version 4.5.3. The cordova-plugins `cordova-plugin-console`,
- `cordova-plugin-device-motion`, and `cordova-plugin-device-orientation` have been
- [deprecated](https://cordova.apache.org/news/2017/09/22/plugins-release.html)
+## v1.8, 2018-10-08
+
+### Breaking changes
+N/A
+
+### Migration Steps
+
+* Update the `@babel/runtime` npm package to version 7.0.0 or later:
+
+ ```sh
+ meteor npm install @babel/runtime@latest
+ ```
+
+### Changes
+
+* Although Node 8.12.0 has been released, Meteor 1.8 still uses Node
+ 8.11.4, due to concerns about excessive garbage collection and CPU usage
+ in production. To enable Galaxy customers to use Node 8.12.0, we are
+ planning a quick follow-up Meteor 1.8.1 release, which can be obtained
+ by running the command
+ ```bash
+ meteor update --release 1.8.1
+ ```
+ [Issue #10216](https://github.com/meteor/meteor/issues/10216)
+
+* Meteor 1.7 introduced a new client bundle called `web.browser.legacy` in
+ addition to the `web.browser` (modern) and `web.cordova` bundles.
+ Naturally, this extra bundle increased client (re)build times. Since
+ developers spend most of their time testing the modern bundle in
+ development, and the legacy bundle mostly provides a safe fallback in
+ production, Meteor 1.8 cleverly postpones building the legacy bundle
+ until just after the development server restarts, so that development
+ can continue as soon as the modern bundle has finished building. Since
+ the legacy build happens during a time when the build process would
+ otherwise be completely idle, the impact of the legacy build on server
+ performance is minimal. Nevertheless, the legacy bundle still gets
+ rebuilt regularly, so any legacy build errors will be surfaced in a
+ timely fashion, and legacy clients can test the new legacy bundle by
+ waiting a bit longer than modern clients. Applications using the
+ `autoupdate` or `hot-code-push` packages will reload modern and legacy
+ clients independently, once each new bundle becomes available.
+ [Issue #9948](https://github.com/meteor/meteor/issues/9948)
+ [PR #10055](https://github.com/meteor/meteor/pull/10055)
+
+* Compiler plugins that call `inputFile.addJavaScript` or
+ `inputFile.addStylesheet` may now delay expensive compilation work by
+ passing partial options (`{ path, hash }`) as the first argument,
+ followed by a callback function as the second argument, which will be
+ called by the build system once it knows the module will actually be
+ included in the bundle. For example, here's the old implementation of
+ `BabelCompiler#processFilesForTarget`:
+ ```js
+ processFilesForTarget(inputFiles) {
+ inputFiles.forEach(inputFile => {
+ var toBeAdded = this.processOneFileForTarget(inputFile);
+ if (toBeAdded) {
+ inputFile.addJavaScript(toBeAdded);
+ }
+ });
+ }
+ ```
+ and here's the new version:
+ ```js
+ processFilesForTarget(inputFiles) {
+ inputFiles.forEach(inputFile => {
+ if (inputFile.supportsLazyCompilation) {
+ inputFile.addJavaScript({
+ path: inputFile.getPathInPackage(),
+ hash: inputFile.getSourceHash(),
+ }, function () {
+ return this.processOneFileForTarget(inputFile);
+ });
+ } else {
+ var toBeAdded = this.processOneFileForTarget(inputFile);
+ if (toBeAdded) {
+ inputFile.addJavaScript(toBeAdded);
+ }
+ }
+ });
+ }
+ ```
+ If you are an author of a compiler plugin, we strongly recommend using
+ this new API, since unnecessary compilation of files that are not
+ included in the bundle can be a major source of performance problems for
+ compiler plugins. Although this new API is only available in Meteor 1.8,
+ you can use `inputFile.supportsLazyCompilation` to determine dynamically
+ whether the new API is available, so you can support older versions of
+ Meteor without having to publish multiple versions of your package. [PR
+ #9983](https://github.com/meteor/meteor/pull/9983)
+
+* New [React](https://reactjs.org/)-based Meteor applications can now be
+ created using the command
+ ```bash
+ meteor create --react new-react-app
+ ```
+ Though relatively simple, this application template reflects the ideas
+ of many contributors, especially [@dmihal](https://github.com/dmihal)
+ and [@alexsicart](https://github.com/alexsicart), and it will no doubt
+ continue to evolve in future Meteor releases.
+ [Feature #182](https://github.com/meteor/meteor-feature-requests/issues/182)
+ [PR #10149](https://github.com/meteor/meteor/pull/10149)
+
+* The `.meteor/packages` file supports a new syntax for overriding
+ problematic version constraints from packages you do not control.
+
+ If a package version constraint in `.meteor/packages` ends with a `!`
+ character, any other (non-`!`) constraints on that package elsewhere in
+ the application will be _weakened_ to allow any version greater than or
+ equal to the constraint, even if the major/minor versions do not match.
+
+ For example, using both CoffeeScript 2 and `practicalmeteor:mocha` used
+ to be impossible (or at least very difficult) because of this
+ [`api.versionsFrom("1.3")`](https://github.com/practicalmeteor/meteor-mocha/blob/3a2658070a920f8846df48bb8d8c7b678b8c6870/package.js#L28)
+ statement, which unfortunately constrained the `coffeescript` package to
+ version 1.x. In Meteor 1.8, if you want to update `coffeescript` to
+ 2.x, you can relax the `practicalmeteor:mocha` constraint by putting
+ ```
+ coffeescript@2.2.1_1! # note the !
+ ```
+ in your `.meteor/packages` file. The `coffeescript` version still needs
+ to be at least 1.x, so that `practicalmeteor:mocha` can count on that
+ minimum. However, `practicalmeteor:mocha` will no longer constrain the
+ major version of `coffeescript`, so `coffeescript@2.2.1_1` will work.
+
+ [Feature #208](https://github.com/meteor/meteor-feature-requests/issues/208)
+ [Commit 4a70b12e](https://github.com/meteor/meteor/commit/4a70b12eddef00b6700f129e90018a6076cb1681)
+ [Commit 9872a3a7](https://github.com/meteor/meteor/commit/9872a3a71df033e4cf6290b75fea28f44427c0c2)
+
+* The `npm` package has been upgraded to version 6.4.1, and our
+ [fork](https://github.com/meteor/pacote/tree/v8.1.6-meteor) of its
+ `pacote` dependency has been rebased against version 8.1.6.
+
+* The `node-gyp` npm package has been updated to version 3.7.0, and the
+ `node-pre-gyp` npm package has been updated to version 0.10.3.
+
+* Scripts run via `meteor npm ...` can now use the `meteor` command more
+ safely, since the `PATH` environment variable will now be set so that
+ `meteor` always refers to the same `meteor` used to run `meteor npm`.
+ [PR #9941](https://github.com/meteor/meteor/pull/9941)
+
+* Minimongo's behavior for sorting fields containing an array
+ is now compatible with the behavior of [Mongo 3.6+](https://docs.mongodb.com/manual/release-notes/3.6-compatibility/#array-sort-behavior).
+ Note that this means it is now incompatible with the behavior of earlier MongoDB versions.
+ [PR #10214](https://github.com/meteor/meteor/pull/10214)
+
+* Meteor's `self-test` has been updated to use "headless" Chrome rather
+ than PhantomJS for browser tests. PhantomJS can still be forced by
+ passing the `--phantom` flag to the `meteor self-test` command.
+ [PR #9814](https://github.com/meteor/meteor/pull/9814)
+
+* Importing a directory containing an `index.*` file now works for
+ non-`.js` file extensions. As before, the list of possible extensions is
+ defined by which compiler plugins you have enabled.
+ [PR #10027](https://github.com/meteor/meteor/pull/10027)
+
+* Any client (modern or legacy) may now request any static JS or CSS
+ `web.browser` or `web.browser.legacy` resource, even if it was built for
+ a different architecture, which greatly simplifies CDN setup if your CDN
+ does not forward the `User-Agent` header to the origin.
+ [Issue #9953](https://github.com/meteor/meteor/issues/9953)
+ [PR #9965](https://github.com/meteor/meteor/pull/9965)
+
+* Cross-origin dynamic `import()` requests will now succeed in more cases.
+ [PR #9954](https://github.com/meteor/meteor/pull/9954)
+
+* Dynamic CSS modules (which are compiled to JS and handled like any other
+ JS module) will now be properly minified in production and source mapped
+ in development. [PR #9998](https://github.com/meteor/meteor/pull/9998)
+
+* While CSS is only minified in production, CSS files must be merged
+ together into a single stylesheet in both development and production.
+ This merging is [cached by `standard-minifier-css`](https://github.com/meteor/meteor/blob/183d5ff9500d908d537f58d35ce6cd6d780ab270/packages/standard-minifier-css/plugin/minify-css.js#L58-L62)
+ so that it does not happen on every rebuild in development, but not all
+ CSS minifier packages use the same caching techniques. Thanks to
+ [1ed095c36d](https://github.com/meteor/meteor/pull/9942/commits/1ed095c36d7b2915872eb0c943dae0c4f870d7e4),
+ this caching is now performed within the Meteor build tool, so it works
+ the same way for all CSS minifier packages, which may eliminate a few
+ seconds of rebuild time for projects with lots of CSS.
+
+* The `meteor-babel` npm package used by `babel-compiler` has been updated
+ to version 7.1.0. **Note:** This change _requires_ also updating the
+ `@babel/runtime` npm package to version 7.0.0-beta.56 or later:
+ ```sh
+ meteor npm install @babel/runtime@latest
+ ```
+ [`meteor-babel` issue #22](https://github.com/meteor/babel/issues/22)
+
+* The `@babel/preset-env` and `@babel/preset-react` presets will be
+ ignored by Meteor if included in a `.babelrc` file, since Meteor already
+ provides equivalent/superior functionality without them. However, you
+ should feel free to leave these plugins in your `.babelrc` file if they
+ are needed by external tools.
+
+* The `install` npm package used by `modules-runtime` has been updated to
+ version 0.12.0.
+
+* The `reify` npm package has been updated to version 0.17.3, which
+ introduces the `module.link(id, {...})` runtime method as a replacement
+ for `module.watch(require(id), {...})`. Note: in future versions of
+ `reify` and Meteor, the `module.watch` runtime API will be removed, but
+ for now it still exists (and is used to implement `module.link`), so
+ that existing code will continue to work without recompilation.
+
+* The `uglify-es` npm package used by `minifier-js` has been replaced with
+ [`terser@3.9.2`](https://www.npmjs.com/package/terser), a fork of
+ `uglify-es` that appears to be (more actively) maintained.
+ [Issue #10042](https://github.com/meteor/meteor/issues/10042)
+
+* Mongo has been updated to version 4.0.2 and the `mongodb` npm package
+ used by `npm-mongo` has been updated to version 3.1.6.
+ [PR #10058](https://github.com/meteor/meteor/pull/10058)
+ [Feature Request #269](https://github.com/meteor/meteor-feature-requests/issues/269)
+
+* When a Meteor application uses a compiler plugin to process files with a
+ particular file extension (other than `.js` or `.json`), those file
+ extensions should be automatically appended to imports that do not
+ resolve as written. However, this behavior was not previously enabled
+ for modules inside `node_modules`. Thanks to
+ [8b04c25390](https://github.com/meteor/meteor/pull/9942/commits/8b04c253900e4ca2a194d2fcaf6fc2ce9a9085e7),
+ the same file extensions that are applied to modules outside the
+ `node_modules` directory will now be applied to those within it, though
+ `.js` and `.json` will always be tried first.
+
+* As foreshadowed in this [talk](https://youtu.be/vpCotlPieIY?t=29m18s)
+ about Meteor 1.7's modern/legacy bundling system
+ ([slides](https://slides.com/benjamn/meteor-night-may-2018#/46)), Meteor
+ now provides an isomorphic implementation of the [WHATWG `fetch()`
+ API](https://fetch.spec.whatwg.org/), which can be installed by running
+ ```sh
+ meteor add fetch
+ ```
+ This package is a great demonstration of the modern/legacy bundling
+ system, since it has very different implementations in modern
+ browsers, legacy browsers, and Node.
+ [PR #10029](https://github.com/meteor/meteor/pull/10029)
+
+* The [`bundle-visualizer`
+ package](https://github.com/meteor/meteor/tree/release-1.7.1/packages/non-core/bundle-visualizer)
+ has received a number of UI improvements thanks to work by
+ [@jamesmillerburgess](https://github.com/jamesmillerburgess) in
+ [PR #10025](https://github.com/meteor/meteor/pull/10025).
+ [Feature #310](https://github.com/meteor/meteor-feature-requests/issues/310)
+
+* Sub-resource integrity hashes (sha512) can now be enabled for static CSS
+ and JS assets by calling `WebAppInternals.enableSubresourceIntegrity()`.
+ [PR #9933](https://github.com/meteor/meteor/pull/9933)
+ [PR #10050](https://github.com/meteor/meteor/pull/10050)
+
+* The environment variable `METEOR_PROFILE=milliseconds` now works for the
+ build portion of the `meteor build` and `meteor deploy` commands.
+ [Feature #239](https://github.com/meteor/meteor-feature-requests/issues/239)
+
+* Babel compiler plugins will now receive a `caller` option of the
+ following form:
+ ```js
+ { name: "meteor", arch }
+ ```
+ where `arch` is the target architecture, e.g. `os.*`, `web.browser`,
+ `web.cordova`, or `web.browser.legacy`.
+ [PR #10211](https://github.com/meteor/meteor/pull/10211)
+
+## v1.7.0.5, 2018-08-16
+
+### Breaking changes
+N/A
+
+### Migration Steps
+N/A
+
+### Changes
+
+* Node has been updated to version
+ [8.11.4](https://nodejs.org/en/blog/release/v8.11.4/), an important
+ [security release](https://nodejs.org/en/blog/vulnerability/august-2018-security-releases/).
+
+## v1.7.0.4, 2018-08-07
+
+### Breaking changes
+N/A
+
+### Migration Steps
+N/A
+
+### Changes
+
+* The npm package `@babel/runtime`, which is depended on by most Meteor
+ apps, introduced a breaking change in version `7.0.0-beta.56` with the
+ removal of the `@babel/runtime/helpers/builtin` directory. While this
+ change has clear benefits in the long term, in the short term it has
+ been disruptive for Meteor 1.7.0.x applications that accidentally
+ updated to the latest version of `@babel/runtime`. Meteor 1.7.0.4 is a
+ patch release that provides better warnings about this problem, and
+ ensures newly created Meteor applications do not use `7.0.0-beta.56`.
+ [PR #10134](https://github.com/meteor/meteor/pull/10134)
+
+* The `npm` package has been upgraded to version 6.3.0, and our
+ [fork](https://github.com/meteor/pacote/tree/v8.1.6-meteor) of its
+ `pacote` dependency has been rebased against version 8.1.6.
+ [Issue #9940](https://github.com/meteor/meteor/issues/9940)
+
+* The `reify` npm package has been updated to version 0.16.4.
+
+## v1.7.0.3, 2018-06-13
+
+### Breaking changes
+N/A
+
+### Migration Steps
+N/A
+
+### Changes
+
+* Fixed [Issue #9991](https://github.com/meteor/meteor/issues/9991),
+ introduced in
+ [Meteor 1.7.0.2](https://github.com/meteor/meteor/pull/9990)
+ by [PR #9977](https://github.com/meteor/meteor/pull/9977).
+
+## v1.7.0.2, 2018-06-13
+
+### Breaking changes
+N/A
+
+### Migration Steps
+N/A
+
+### Changes
+
+* Node has been updated to version
+ [8.11.3](https://nodejs.org/en/blog/release/v8.11.3/), an important
+ [security release](https://nodejs.org/en/blog/vulnerability/june-2018-security-releases/).
+
+* The `meteor-babel` npm package has been updated to version
+ [7.0.0-beta.51](https://github.com/babel/babel/releases/tag/v7.0.0-beta.51).
+
+* Meteor apps created with `meteor create` or `meteor create --minimal`
+ will now have a directory called `tests/` rather than `test/`, so that
+ test code will not be eagerly loaded if you decide to remove the
+ `meteor.mainModule` configuration from `package.json`, thanks to
+ [PR #9977](https://github.com/meteor/meteor/pull/9977) by
+ [@robfallows](https://github.com/robfallows).
+ [Issue #9961](https://github.com/meteor/meteor/issues/9961)
+
+## v1.7.0.1, 2018-05-29
+
+### Breaking changes
+
+* The `aggregate` method of raw Mongo collections now returns an
+ `AggregationCursor` rather than returning the aggregation result
+ directly. To obtain an array of aggregation results, you will need to
+ call the `.toArray()` method of the cursor:
+ ```js
+ // With MongoDB 2.x, callback style:
+ rawCollection.aggregate(
+ pipeline,
+ (error, results) => {...}
+ );
+
+ // With MongoDB 2.x, wrapAsync style:
+ const results = Meteor.wrapAsync(
+ rawCollection.aggregate,
+ rawCollection
+ )(pipeline);
+
+ // With MongoDB 3.x, callback style:
+ rawCollection.aggregate(
+ pipeline,
+ (error, aggregationCursor) => {
+ ...
+ const results = aggregationCursor.toArray();
+ ...
+ }
+ );
+
+ // With MongoDB 3.x, wrapAsync style:
+ const results = Meteor.wrapAsync(
+ rawCollection.aggregate,
+ rawCollection
+ )(pipeline).toArray();
+ ```
+ [Issue #9936](https://github.com/meteor/meteor/issues/9936)
+
+### Migration Steps
+
+* Update `@babel/runtime` (as well as other Babel-related packages) and
+ `meteor-node-stubs` to their latest versions:
+ ```sh
+ meteor npm install @babel/runtime@latest meteor-node-stubs@latest
+ ```
+
+### Changes
+
+* Reverted an [optimization](https://github.com/meteor/meteor/pull/9825)
+ introduced in Meteor 1.7 to stop scanning `node_modules` for files that
+ might be of interest to compiler plugins, since the intended workarounds
+ (creating symlinks) did not satisfy all existing use cases. We will
+ revisit this optimization in Meteor 1.8.
+ [mozfet/meteor-autoform-materialize#43](https://github.com/mozfet/meteor-autoform-materialize/issues/43)
+
+* After updating to Meteor 1.7 or 1.7.0.1, you should update the
+ `@babel/runtime` npm package (as well as other Babel-related packages)
+ to their latest versions, along with the `meteor-node-stubs` package,
+ by running the following command:
+ ```sh
+ meteor npm install @babel/runtime@latest meteor-node-stubs@latest
+ ```
+
+## v1.7, 2018-05-28
+
+### Breaking changes
+N/A
+
+### Migration Steps
+N/A
+
+### Changes
+
+* More than 80% of internet users worldwide have access to a web browser
+ that natively supports the latest ECMAScript features and keeps itself
+ updated automatically, which means new features become available almost
+ as soon as they ship. In other words, the future we envisioned when we
+ first began [compiling code with
+ Babel](https://blog.meteor.com/how-much-does-ecmascript-2015-cost-2ded41d70914)
+ is finally here, yet most web frameworks and applications still compile
+ a single client-side JavaScript bundle that must function simultaneously
+ in the oldest and the newest browsers the application developer wishes
+ to support.
+
+ That choice is understandable, because the alternative is daunting: not
+ only must you build multiple JavaScript and CSS bundles for different
+ browsers, with different dependency graphs and compilation rules and
+ webpack configurations, but your server must also be able to detect the
+ capabilities of each visiting client, so that it can deliver the
+ appropriate assets at runtime. Testing a matrix of different browsers
+ and application versions gets cumbersome quickly, so it's no surprise
+ that responsible web developers would rather ship a single, well-tested
+ bundle, and forget about taking advantage of modern features until
+ legacy browsers have disappeared completely.
+
+ With Meteor 1.7, this awkward balancing act is no longer necessary,
+ because Meteor now automatically builds two sets of client-side assets,
+ one tailored to the capabilities of modern browsers, and the other
+ designed to work in all supported browsers, thus keeping legacy browsers
+ working exactly as they did before. Best of all, the entire Meteor
+ community relies on the same system, so any bugs or differences in
+ behavior can be identified and fixed quickly.
+
+ In this system, a "modern" browser can be loosely defined as one with
+ full native support for `async` functions and `await` expressions, which
+ includes more than 80% of the world market, and 85% of the US market
+ ([source](https://caniuse.com/#feat=async-functions)). This standard may
+ seem extremely strict, since `async`/`await` was [just finalized in
+ ECMAScript 2017](http://2ality.com/2016/10/async-function-tips.html),
+ but the statistics clearly justify it. As another example, any modern
+ browser can handle native `class` syntax, though newer syntax like class
+ fields may still need to be compiled for now, whereas a legacy browser
+ will need compilation for both advanced and basic `class` syntax. And of
+ course you can safely assume that any modern browser has a native
+ `Promise` implementation, because `async` functions must return
+ `Promise`s. The list goes on and on.
+
+ This boundary between modern and legacy browsers is designed to be tuned
+ over time, not only by the Meteor framework itself but also by each
+ individual Meteor application. For example, here's how the minimum
+ versions for native ECMAScript `class` support might be expressed:
+
+ ```js
+ import { setMinimumBrowserVersions } from "meteor/modern-browsers";
+
+ setMinimumBrowserVersions({
+ chrome: 49,
+ firefox: 45,
+ edge: 12,
+ ie: Infinity, // Sorry, IE11.
+ mobile_safari: [9, 2], // 9.2.0+
+ opera: 36,
+ safari: 9,
+ electron: 1,
+ }, "classes");
+ ```
+
+ The minimum modern version for each browser is simply the maximum of all
+ versions passed to `setMinimumBrowserVersions` for that browser. The
+ Meteor development server decides which assets to deliver to each client
+ based on the `User-Agent` string of the HTTP request. In production,
+ different bundles are named with unique hashes, which prevents cache
+ collisions, though Meteor also sets the `Vary: User-Agent` HTTP response
+ header to let well-behaved clients know they should cache modern and
+ legacy resources separately.
+
+ For the most part, the modern/legacy system will transparently determine
+ how your code is compiled, bundled, and delivered—and yes, it
+ works with every existing part of Meteor, including dynamic `import()`
+ and even [the old `appcache`
+ package](https://github.com/meteor/meteor/pull/9776). However, if you're
+ writing dynamic code that depends on modern features, you can use the
+ boolean `Meteor.isModern` flag to detect the status of the current
+ environment (Node 8 is modern, too, of course). If you're writing a
+ Meteor package, you can call `api.addFiles(files, "legacy")` in your
+ `package.js` configuration file to add extra files to the legacy bundle,
+ or `api.addFiles(files, "client")` to add files to all client bundles,
+ or `api.addFiles(files, "web.browser")` to add files only to the modern
+ bundle, and the same rules apply to `api.mainModule`. Just be sure to
+ call `setMinimumBrowserVersions` (in server startup code) to enforce
+ your assumptions about ECMAScript feature support.
+
+ We think this modern/legacy system is one of the most powerful features
+ we've added since we first introduced the `ecmascript` package in Meteor
+ 1.2, and we look forward to other frameworks attempting to catch up.
+
+ [PR #9439](https://github.com/meteor/meteor/pull/9439)
+
+* Although Meteor does not recompile packages installed in `node_modules`
+ by default, compilation of specific npm packages (for example, to
+ support older browsers that the package author neglected) can now be
+ enabled in one of two ways:
+
+ * Clone the package repository into your application's `imports`
+ directory, make any modifications necessary, then use `npm install` to
+ link `the-package` into `node_modules`:
+ ```sh
+ meteor npm install imports/the-package
+ ```
+ Meteor will compile the contents of the package exposed via
+ `imports/the-package`, and this compiled code will be used when you
+ import `the-package` in any of the usual ways:
+ ```js
+ import stuff from "the-package"
+ require("the-package") === require("/imports/the-package")
+ import("the-package").then(...)
+ ```
+ This reuse of compiled code is the critical new feature that was added
+ in Meteor 1.7.
+
+ * Install the package normally with `meteor npm install the-package`,
+ then create a symbolic link *to* the installed package elsewhere in
+ your application, outside of `node_modules`:
+ ```sh
+ meteor npm install the-package
+ cd imports
+ ln -s ../node_modules/the-package .
+ ```
+ Again, Meteor will compile the contents of the package because they
+ are exposed outside of `node_modules`, and the compiled code will be
+ used whenever `the-package` is imported from `node_modules`.
+
+ > Note: this technique also works if you create symbolic links to
+ individual files, rather than linking the entire package directory.
+
+ In both cases, Meteor will compile the exposed code as if it was part of
+ your application, using whatever compiler plugins you have installed.
+ You can influence this compilation using `.babelrc` files or any other
+ techniques you would normally use to configure compilation of
+ application code. [PR #9771](https://github.com/meteor/meteor/pull/9771)
+ [Feature #6](https://github.com/meteor/meteor-feature-requests/issues/6)
+
+ > ~Note: since compilation of npm packages can now be enabled using the
+ techniques described above, Meteor will no longer automatically scan
+ `node_modules` directories for modules that can be compiled by
+ compiler plugins. If you have been using that functionality to import
+ compiled-to-JS modules from `node_modules`, you should start using the
+ symlinking strategy instead.~ **Follow-up note: this optimization was
+ reverted in Meteor 1.7.0.1 (see [above](#v1701-2018-05-29)).**
+
+* Node has been updated to version
+ [8.11.2](https://nodejs.org/en/blog/release/v8.11.2/), officially fixing
+ a [cause](https://github.com/nodejs/node/issues/19274) of frequent
+ segmentation faults in Meteor applications that was introduced in Node
+ 8.10.0. Meteor 1.6.1.1 shipped with a custom build of Node that patched
+ this problem, but that approach was never intended to be permanent.
+
+* The `npm` package has been upgraded to version 5.10.0, and our
+ [fork](https://github.com/meteor/pacote/tree/v7.6.1-meteor) of its
+ `pacote` dependency has been rebased against version 7.6.1.
+
+* Applications may now specify client and server entry point modules in a
+ newly-supported `"meteor"` section of `package.json`:
+ ```js
+ "meteor": {
+ "mainModule": {
+ "client": "client/main.js",
+ "server": "server/main.js"
+ }
+ }
+ ```
+ When specified, these entry points override Meteor's default module
+ loading semantics, rendering `imports` directories unnecessary. If
+ `mainModule` is left unspecified for either client or server, the
+ default rules will apply for that architecture, as before. To disable
+ eager loading of modules on a given architecture, simply provide a
+ `mainModule` value of `false`:
+ ```js
+ "meteor": {
+ "mainModule": {
+ "client": false,
+ "server": "server/main.js"
+ }
+ }
+ ```
+ [Feature #135](https://github.com/meteor/meteor-feature-requests/issues/135)
+ [PR #9690](https://github.com/meteor/meteor/pull/9690)
+
+* In addition to `meteor.mainModule`, the `"meteor"` section of
+ `package.json` may also specify `meteor.testModule` to control which
+ test modules are loaded by `meteor test` or `meteor test --full-app`:
+ ```js
+ "meteor": {
+ "mainModule": {...},
+ "testModule": "tests.js"
+ }
+ ```
+ If your client and server test files are different, you can expand the
+ `testModule` configuration using the same syntax as `mainModule`:
+ ```js
+ "meteor": {
+ "testModule": {
+ "client": "client/tests.js",
+ "server": "server/tests.js"
+ }
+ }
+ ```
+ The same test module will be loaded whether or not you use the
+ `--full-app` option. Any tests that need to detect `--full-app` should
+ check `Meteor.isAppTest`. The module(s) specified by `meteor.testModule`
+ can import other test modules at runtime, so you can still distribute
+ test files across your codebase; just make sure you import the ones you
+ want to run. [PR #9714](https://github.com/meteor/meteor/pull/9714)
+
+* The `meteor create` command now supports a `--minimal` option, which
+ creates an app with as few Meteor packages as possible, in order to
+ minimize client bundle size while still demonstrating advanced features
+ such as server-side rendering. This starter application is a solid
+ foundation for any application that doesn't need Mongo or DDP.
+
+* The `meteor-babel` npm package has been updated to version
+ 7.0.0-beta.49-1. Note: while Babel has recently implemented support for
+ a new kind of `babel.config.js` configuration file (see [this
+ PR](https://github.com/babel/babel/pull/7358)), and future versions of
+ Meteor will no doubt embrace this functionality, Meteor 1.7 supports
+ only `.babelrc` files as a means of customizing the default Babel
+ configuration provided by Meteor. In other words, if your project
+ contains a `babel.config.js` file, it will be ignored by Meteor 1.7.
+
+* The `reify` npm package has been updated to version 0.16.2.
+
+* The `meteor-node-stubs` package, which provides stub implementations for
+ any Node built-in modules used by the client (such as `path` and
+ `http`), has a new minor version (0.4.1) that may help with Windows
+ installation problems. To install the new version, run
+ ```sh
+ meteor npm install meteor-node-stubs@latest
+ ```
+
+* The `optimism` npm package has been updated to version 0.6.3.
+
+* The `minifier-js` package has been updated to use `uglify-es` 3.3.9.
+
+* Individual Meteor `self-test`'s can now be skipped by adjusting their
+ `define` call to be prefixed by `skip`. For example,
+ `selftest.skip.define('some test', ...` will skip running "some test".
+ [PR #9579](https://github.com/meteor/meteor/pull/9579)
+
+* Mongo has been upgraded to version 3.6.4 for 64-bit systems, and 3.2.19
+ for 32-bit systems. [PR #9632](https://github.com/meteor/meteor/pull/9632)
+
+ **NOTE:** After upgrading an application to use Mongo 3.6.4, it has been
+ observed ([#9591](https://github.com/meteor/meteor/issues/9591))
+ that attempting to run that application with an older version of
+ Meteor (via `meteor --release X`), that uses an older version of Mongo, can
+ prevent the application from starting. This can be fixed by either
+ running `meteor reset`, or by repairing the Mongo database. To repair the
+ database, find the `mongod` binary on your system that lines up with the
+ Meteor release you're jumping back to, and run
+ `mongodb --dbpath your-apps-db --repair`. For example:
+ ```sh
+ ~/.meteor/packages/meteor-tool/1.6.0_1/mt-os.osx.x86_64/dev_bundle/mongodb/bin/mongod --dbpath /my-app/.meteor/local/db --repair
+ ```
+ [PR #9632](https://github.com/meteor/meteor/pull/9632)
+
+* The `mongodb` driver package has been updated from version 2.2.34 to
+ version 3.0.7. [PR #9790](https://github.com/meteor/meteor/pull/9790)
+ [PR #9831](https://github.com/meteor/meteor/pull/9831)
+ [Feature #268](https://github.com/meteor/meteor-feature-requests/issues/268)
+
+* The `cordova-plugin-meteor-webapp` package depended on by the Meteor
+ `webapp` package has been updated to version 1.6.0.
+ [PR #9761](https://github.com/meteor/meteor/pull/9761)
+
+* Any settings read from a JSON file passed with the `--settings` option
+ during Cordova run/build/deploy will be exposed in `mobile-config.js`
+ via the `App.settings` property, similar to `Meteor.settings`.
+ [PR #9873](https://github.com/meteor/meteor/pull/9873)
+
+* The `@babel/plugin-proposal-class-properties` plugin provided by
+ `meteor-babel` now runs with the `loose:true` option, as required by
+ other (optional) plugins like `@babel/plugin-proposal-decorators`.
+ [Issue #9628](https://github.com/meteor/meteor/issues/9628)
+
+* The `underscore` package has been removed as a dependency from `meteor-base`.
+ This opens up the possibility of removing 14.4 kb from production bundles.
+ Since this would be a breaking change for any apps that may have been
+ using `_` without having any packages that depend on `underscore`
+ besides `meteor-base`, we have added an upgrader that will automatically
+ add `underscore` to the `.meteor/packages` file of any project which
+ lists `meteor-base`, but not `underscore`. Apps which do not require this
+ package can safely remove it using `meteor remove underscore`.
+ [PR #9596](https://github.com/meteor/meteor/pull/9596)
+
+* Meteor's `promise` package has been updated to support
+ [`Promise.prototype.finally`](https://github.com/tc39/proposal-promise-finally).
+ [Issue 9639](https://github.com/meteor/meteor/issues/9639)
+ [PR #9663](https://github.com/meteor/meteor/pull/9663)
+
+* Assets made available via symlinks in the `public` and `private` directories
+ of an application are now copied into Meteor application bundles when
+ using `meteor build`. This means npm package assets that need to be made
+ available publicly can now be symlinked from their `node_modules` location,
+ in the `public` directory, and remain available in production bundles.
+ [Issue #7013](https://github.com/meteor/meteor/issues/7013)
+ [PR #9666](https://github.com/meteor/meteor/pull/9666)
+
+* The `facts` package has been split into `facts-base` and `facts-ui`. The
+ original `facts` package has been deprecated.
+ [PR #9629](https://github.com/meteor/meteor/pull/9629)
+
+* If the new pseudo tag `` is used anywhere in the
+ ` ` of an app, it will be replaced by the `link` to Meteor's bundled
+ CSS. If the new tag isn't used, the bundle will be placed at the top of
+ the `