Merge branch 'devel' into release-1.5.2

2026-05-02 03:01:46 -04:00 · 2017-08-11 15:23:39 -04:00
parent 999196b515 93d0c5f2ba
commit 0e723593a6
9 changed files with 152 additions and 57 deletions
--- a/.github/ISSUE_TEMPLATE.md
+++ b/.github/ISSUE_TEMPLATE.md
@@ -1,20 +1,32 @@
-**NOTE:** Issues in this repository are reserved for bugs only. To submit a feature request, please open a new issue in the [meteor/meteor-feature-requests](https://github.com/meteor/meteor-feature-requests) repository.
+<!--
+* ❓ Questions?
+          Use Stack Overflow (http://stackoverflow.com/questions/tagged/meteor)
+          or start a discussion on the Meteor forums (https://forums.meteor.com/).
+* 💡 Feature requests?
+          Visit the feature request repository (https://github.com/meteor/meteor-feature-requests).
+* ❗️ Bug?
+          This is the right place!

-Remember, an issue is not the place to ask questions. You can use [Stack Overflow](http://stackoverflow.com/questions/tagged/meteor) for that, or you may want to start a discussion on the [Meteor forum](https://forums.meteor.com/).
+Before reporting a bug, please check for existing or closed issues
+first and read the instructions for filing a bug report:
+https://github.com/meteor/meteor/blob/devel/Contributing.md#reporting-a-bug-in-meteor

-Before you open an issue, please check if a similar issue already exists or has been closed before.
-
-### When reporting a bug, please be sure to include the following:
+### This bug report should include:
 - [ ] A descriptive title
- [ ] What version of Meteor you're using, and the platform(s) you're running it on
- [ ] What packages or other dependencies you're using
- [ ] The behavior you expect to see, and the actual behavior
- [ ] An *isolated* way to reproduce the behavior (example: GitHub repository with code isolated to the issue that anyone can clone to observe the problem)
+- [ ] The version of Meteor showing the problem.
+- [ ] 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.
+- [ ] A **simple** reproduction!
+      (example: A GitHub repository that anyone can clone to observe the problem.)

-See [here](https://github.com/meteor/meteor/blob/devel/Contributing.md#reporting-a-bug-in-meteor) for more detail on what is expected of a bug report.
+### Independent packages

-### Independent core packages
+Please ensure your issue is opened in the appropriate repository:

-We've split some packages out of meteor/meteor in order to make it easier for community members to contribute and the MDG team to maintain a slimmer core (this enables us to untie package versions from Meteor releases). Please ensure your issue is opened against the appropriate repository. Packages that have been split from core and their repositories are:
-
- Blaze: https://github.com/meteor/blaze
+* Feature Requests: https://github.com/meteor/meteor-feature-requests
+* Blaze: https://github.com/meteor/blaze/
+* Docs: https://github.com/meteor/docs/
+* Guide: https://github.com/meteor/guide
+-->
--- a/Roadmap.md
+++ b/Roadmap.md
@@ -2,7 +2,7 @@

 # Meteor Roadmap

-**Up to date as of March 17, 2017**
+**Up to date as of August 11, 2017**

 This document describes the high level features the Meteor project maintainers have decided to prioritize in the near- to medium-term future. A large fraction of the maintainers’ time will be dedicated to working on the features described here. As with any roadmap, this is a living document that will evolve as priorities and dependencies shift; we aim to update the roadmap with any changes or status updates on a monthly basis.

@@ -10,25 +10,64 @@ Contributors are encouraged to focus their efforts on work that aligns with the

 Items can be added to this roadmap by first getting design approval for a solution to an open issue, as outlined by our [contributing guidelines](https://github.com/meteor/meteor/blob/devel/Contributing.md). Then, when a contributor has committed to solving the issue in the short to medium term, they can submit a PR to add that work to the roadmap. All other PRs to the roadmap will be rejected.

+## Upgrade to Node 8
+
+*Tracking pull request: https://github.com/meteor/meteor/pull/8728*
+
+Upgrading Node will allow Meteor to take better advantage of native support for new ECMAScript features on the server, which should speed up build performance and also improve runtime performance, thanks to performance improvements in Node itself.
+
+Perhaps even more importantly, newer versions of Node support a vastly improved debugging experience. Not only can you use native Chrome DevTools and many other debugging clients (WebStorm, VS Code, etc.) to debug your app (no more [`node-inspector`](https://www.npmjs.com/package/node-inspector)), but also the Node process runs at full speed while debugging, so you don't have to wait as long for problems to manifest themselves.
+
+## Out of the box support for advanced React features
+
+React is the most popular way to build UIs in JavaScript today, and a great companion to the rest of the features provided by Meteor. Meteor's zero-configuration environment provides a great opportunity to make features React apps depend on work out of the box. This includes features like:
+
+1. Automatic selection of development vs. production build of React (completed)
+2. Abstraction for isomorphic server-side rendering ([ongoing](https://github.com/meteor/meteor/blob/devel/packages/server-render/README.md))
+3. Integration of [dynamic imports](https://blog.meteor.com/dynamic-imports-in-meteor-1-5-c6130419c3cd) with React SSR
+4. Full support for optimized CSS-in-JS features of libraries like [styled-components](https://www.styled-components.com/)
+
+We think Meteor has a clear set of benefits when compared to other popular React frameworks like Create React App and Next.js.
+
+## Remove blockers to Meteor adoption
+
+### Support the latest version of Node
+
+*Tracking pull request: https://github.com/meteor/meteor/pull/8728*
+
+See [above](https://github.com/meteor/meteor/blob/devel/Roadmap.md#upgrade-to-node-8). Developers deserve to use the latest underlying technologies, and Meteor is uniquely able to smooth over any rough edges in early/experimental versions of technologies like Node. A number of developers are already using beta versions of Meteor 1.6 to deploy their apps, because the benefits outweigh the risks for them. Just as Meteor 1.5 climbed to more than 50% usage in less than two months, we expect Meteor 1.6 to become the most widely used version of Meteor soon after its release.
+
+### Make Mongo more optional
+
+*Preliminary solution: https://github.com/meteor/meteor/pull/8999*
+
+Meteor has depended on Mongo for as long as the Meteor project has existed. However, we care deeply about supporting other data storage systems (especially via [GraphQL](https://www.apollodata.com/)), and would like to make it possible to avoid using Mongo altogether.
+
+### Get rid of the `imports` directory
+
+When Meteor 1.3 first introduced a module system based on [CommonJS](http://wiki.commonjs.org/wiki/Modules/1.1) and [ECMAScript module syntax](2ality.com/2014/09/es6-modules-final.html), we had to provide a way for developers to migrate their apps from the old ways of loading code, whereby all files were evaluated eagerly during application startup.
+
+The best solution at the time was to introduce a special `imports` directory to contain modules that should be loaded lazily (rather than eagerly), when first imported.
+
+Most other Node applications work this way by default: every module is lazy, and therefore must be imported by another module, and evaluation starts with one "entry point" module (typically specified by the `"main"` field in `package.json`).
+
+It should be possible for Meteor apps to opt into this behavior, and optionally get rid of their special `imports` directories. The mechanism for opting in will very likely involve putting something in your `package.json` file that specifies entry point modules for both client and server.
+
+### Make the `meteor` command-line tool installable from npm
+
+Installing `meteor` from npm would enable developers to use it as build tool for npm-based projects, and would simplify the Meteor release process by getting rid of the "dev bundle" (essentially the npm dependencies of the command-line tool).
+
+The biggest blockers to this project are
+
+1. deciding whether/how to preserve Meteor release versions, and
+2. changing the API of the package server so that you don't have to download the entire package database locally.

 ## Page load performance improvements

-*Tracking pull request: https://github.com/meteor/meteor/pull/8327*
-
-Just as Meteor 1.4.2 took aim at rebuild performance, Meteor 1.5 will be all about production app performance, specifically client-side application startup time.
-
-Fast initial page load times are somewhat less important for single-page reactive web apps than for other kinds of websites, but large Meteor apps with lots of packages tend to load quite a bit of JavaScript, and the cost of all that network traffic, parsing, and evaluation definitely adds up.
+*Ongoing*

 Speeding up page load times will require a combination of new tools for asynchronous JavaScript delivery (code splitting), dead code elimination, deferred evaluation of JavaScript modules, and performance profiling (so that developers can identify expensive packages).

-### Dynamic `import(...)`
-
-The banner feature of this effort will be first-class support for [dynamic `import(...)`](https://github.com/tc39/proposal-dynamic-import), which enables asynchronous module fetching.
-
-Read the recent [blog post](https://blog.meteor.com/meteor-1-5-react-loadable-f029a320e59c) for an overview of how this system will work in Meteor 1.5.
-
-Remaining work can be found [here](https://github.com/meteor/meteor/blob/release-1.5/packages/dynamic-import/TODO.md), though not all of those ideas will necessarily block the initial 1.5 release.
-
 ### Making large dependencies optional

 Making it possible to remove (or dynamically load) large dependencies like `jquery`, `underscore`, and `minimongo` will have a significant impact on bundle sizes.
@@ -43,12 +82,6 @@ Dynamic `import(...)` benefits dramatically from storing previously-received mod

 Although Meteor minifies JavaScript in production, and modules that are never imported are not included in the client bundle, Meteor could do a better job of removing code within modules that will never be used, according to static analysis. The static syntax of ECMAScript 2015 `import` and `export` declarations should make this analysis easier.

-## Upgrade to Node 6
-
-*Tracking pull request: https://github.com/meteor/meteor/pull/6923*
-
-Upgrading Node will allow Meteor to take better advantage of native support for new ECMAScript features on the server, which should speed up build performance and may also improve runtime performance, thanks to performance improvements in Node itself.
-

 ## Full transition to npm

@@ -73,6 +106,15 @@ Even though Apollo could eventually be a complete replacement for Meteor’s inc

 # **Recently completed**

+## Dynamic `import(...)`
+
+*Status: Shipped in 1.5*
+
+The banner feature of this effort will be first-class support for [dynamic `import(...)`](https://github.com/tc39/proposal-dynamic-import), which enables asynchronous module fetching.
+
+Read the recent [blog post](https://blog.meteor.com/meteor-1-5-react-loadable-f029a320e59c) for an overview of how this system will work in Meteor 1.5.
+
+Remaining work can be found [here](https://github.com/meteor/meteor/blob/release-1.5/packages/dynamic-import/TODO.md), though not all of those ideas will necessarily block the initial 1.5 release.


 ## Rebuild performance improvements
--- a/tools/fs/files.js
+++ b/tools/fs/files.js
@@ -1557,6 +1557,9 @@ function wrapFsFunc(fsFuncName, pathArgIndices, options) {
                         fsFuncName === 'rename' ||
                         fsFuncName === 'symlink');

+      const dirty = options && options.dirty;
+      const dirtyFn = typeof dirty === "function" ? dirty : null;
+
      if (canYield() &&
          shouldBeSync &&
          ! isQuickie) {
@@ -1576,6 +1579,10 @@ function wrapFsFunc(fsFuncName, pathArgIndices, options) {

        const result = promise.await();

+        if (dirtyFn) {
+          dirtyFn(...args);
+        }
+
        return options.modifyReturnValue
          ? options.modifyReturnValue(result)
          : result;
@@ -1584,6 +1591,11 @@ function wrapFsFunc(fsFuncName, pathArgIndices, options) {
        // Should be sync but can't yield: we are not in a Fiber.
        // Run the sync version of the fs.* method.
        const result = fsFuncSync.apply(fs, args);
+
+        if (dirtyFn) {
+          dirtyFn(...args);
+        }
+
        return options.modifyReturnValue ?
               options.modifyReturnValue(result) : result;

@@ -1600,12 +1612,20 @@ function wrapFsFunc(fsFuncName, pathArgIndices, options) {
          args.push((err, res) => {
            err ? reject(err) : resolve(res);
          });
+
          fsFunc.apply(fs, args);
+
        }).then(res => {
+          if (dirtyFn) {
+            dirtyFn(...args);
+          }
+
          if (options.modifyReturnValue) {
            res = options.modifyReturnValue(res);
          }
+
          cb && cb(null, res);
+
        }, cb);

        return;
@@ -1626,8 +1646,27 @@ function wrapFsFunc(fsFuncName, pathArgIndices, options) {
    Profile('wrapped.fs.' + fsFuncName + 'Sync', makeWrapper({ sync: true }));
 }

-wrapFsFunc("writeFile", [0]);
-wrapFsFunc("appendFile", [0]);
+let dependOnPathSalt = 0;
+export const dependOnPath = require("optimism").wrap(
+  // Always return something different to prevent optimism from
+  // second-guessing the dirtiness of this function.
+  path => ++dependOnPathSalt
+);
+
+function wrapDestructiveFsFunc(name, pathArgIndices) {
+  pathArgIndices = pathArgIndices || [0];
+  wrapFsFunc(name, pathArgIndices, {
+    dirty(...args) {
+      // Immediately reset all optimistic functions (defined in
+      // tools/fs/optimistic.js) that depend on these paths.
+      pathArgIndices.forEach(i => dependOnPath.dirty(args[i]));
+    }
+  });
+}
+
+wrapDestructiveFsFunc("writeFile");
+wrapDestructiveFsFunc("appendFile");
+
 wrapFsFunc("readFile", [0], {
  modifyReturnValue: function (fileData) {
    if (_.isString(fileData)) {
@@ -1637,9 +1676,11 @@ wrapFsFunc("readFile", [0], {
    return fileData;
  }
 });
+
 wrapFsFunc("stat", [0]);
 wrapFsFunc("lstat", [0]);
-wrapFsFunc("rename", [0, 1]);
+
+wrapDestructiveFsFunc("rename", [0, 1]);

 // After the outermost files.withCache call returns, the withCacheCache is
 // reset to null so that it does not survive server restarts.
@@ -1748,10 +1789,11 @@ wrapFsFunc("readdir", [0], {
  }
 });

-wrapFsFunc("rmdir", [0]);
-wrapFsFunc("mkdir", [0]);
-wrapFsFunc("unlink", [0]);
-wrapFsFunc("chmod", [0]);
+wrapDestructiveFsFunc("rmdir");
+wrapDestructiveFsFunc("mkdir");
+wrapDestructiveFsFunc("unlink");
+wrapDestructiveFsFunc("chmod");
+
 wrapFsFunc("open", [0]);

 // XXX this doesn't give you the second argument to the callback
--- a/tools/fs/optimistic.js
+++ b/tools/fs/optimistic.js
@@ -10,6 +10,7 @@ import {
  lstat,
  readFile,
  readdir,
+  dependOnPath,
 } from "./files.js";

 // When in doubt, the optimistic caching system can be completely disabled
@@ -18,7 +19,7 @@ const ENABLED = ! process.env.METEOR_DISABLE_OPTIMISTIC_CACHING;

 function makeOptimistic(name, fn) {
  const wrapper = wrap(ENABLED ? function (...args) {
-    maybeDependOnNodeModules(args[0]);
+    maybeDependOnPath(args[0]);
    return fn.apply(this, args);
  } : fn, {
    makeCacheKey(...args) {
@@ -115,6 +116,13 @@ export const shouldWatch = wrap(path => {
  return false;
 });

+function maybeDependOnPath(path) {
+  if (typeof path === "string") {
+    dependOnPath(path);
+    maybeDependOnNodeModules(path);
+  }
+}
+
 function maybeDependOnNodeModules(path) {
  if (typeof path !== "string") {
    return;
--- a/tools/tests/command-line.js
+++ b/tools/tests/command-line.js
@@ -430,7 +430,7 @@ selftest.define("old cli tests (converted)", function () {
  run = s.run("remove", "--help");
  run.match("Removes a package");
  run = s.run("list", "--help");
-  run.match("This will not list transitive dependencies");
+  run.match("Transitive dependencies are not listed unless");
  run = s.run("bundle", "--help");
  run.match("command has been deprecated");
  run = s.run("build", "--help");
--- a/tools/tests/compiler-plugins.js
+++ b/tools/tests/compiler-plugins.js
@@ -22,7 +22,6 @@ function startRun(sandbox) {
 // Tests the actual cache logic used by coffeescript.
 selftest.define("compiler plugin caching - coffee", () => {
  var s = new Sandbox({ fakeMongo: true });
-  s.set("METEOR_WATCH_PRIORITIZE_CHANGED", "false");

  s.createApp("myapp", "caching-coffee");
  s.cd("myapp");
@@ -92,7 +91,6 @@ selftest.define("compiler plugin caching - coffee", () => {

  selftest.define("compiler plugin caching - " + packageName, () => {
    var s = new Sandbox({ fakeMongo: true });
-    s.set("METEOR_WATCH_PRIORITIZE_CHANGED", "false");

    s.createApp("myapp", "caching-" + packageName);
    s.cd("myapp");
@@ -280,7 +278,6 @@ selftest.define("compiler plugin caching - local plugin", function () {
 // Test error on duplicate compiler plugins.
 selftest.define("compiler plugins - duplicate extension", () => {
  const s = new Sandbox({ fakeMongo: true });
-  s.set("METEOR_WATCH_PRIORITIZE_CHANGED", "false");

  s.createApp("myapp", "duplicate-compiler-extensions");
  s.cd("myapp");
--- a/tools/tests/cordova-plugins.js
+++ b/tools/tests/cordova-plugins.js
@@ -136,8 +136,6 @@ selftest.define("change cordova plugins", ["cordova"], function () {
  var s = new Sandbox();
  var run;

-  s.set("METEOR_WATCH_PRIORITIZE_CHANGED", "false");
-
  // Starting a run
  s.createApp("myapp", "package-tests");
  s.cd("myapp");
--- a/tools/tests/package-tests.js
+++ b/tools/tests/package-tests.js
@@ -100,8 +100,6 @@ selftest.define("change packages during hot code push", [], function () {
  var s = new Sandbox();
  var run;

-  s.set("METEOR_WATCH_PRIORITIZE_CHANGED", "false");
-
  // Starting a run
  s.createApp("myapp", "package-tests");
  s.cd("myapp");
--- a/tools/tests/run.js
+++ b/tools/tests/run.js
@@ -22,8 +22,6 @@ selftest.define("run", function () {
  var s = new Sandbox({ fakeMongo: true });
  var run;

-  s.set("METEOR_WATCH_PRIORITIZE_CHANGED", "false");
-
  // Starting a run
  s.createApp("myapp", "standard-app");
  s.cd("myapp");
@@ -264,7 +262,7 @@ selftest.define("update during run", ["checkout", 'custom-warehouse'], function
  run.match('localhost:3000');
  s.write('.meteor/release', DEFAULT_RELEASE_TRACK + '@v2');
  s.write('empty.js', '');
-  run.waitSecs(2);
+  run.waitSecs(10);
  run.match('restarted');
  run.waitSecs(10);
  run.stop();
@@ -274,11 +272,11 @@ selftest.define("update during run", ["checkout", 'custom-warehouse'], function
  s.write('.meteor/release', DEFAULT_RELEASE_TRACK + '@v1');
  run = s.run("--release", DEFAULT_RELEASE_TRACK + "@v1");
  run.tellMongo(MONGO_LISTENING);
-  run.waitSecs(2);
+  run.waitSecs(10);
  run.match('localhost:3000');
  s.write('.meteor/release', DEFAULT_RELEASE_TRACK + '@v2');
  s.write('empty.js', '');
-  run.waitSecs(2);
+  run.waitSecs(10);
  run.match('restarted');
  run.waitSecs(10);
  run.stop();
@@ -292,12 +290,12 @@ selftest.define("update during run", ["checkout", 'custom-warehouse'], function
  s.write('.meteor/release', DEFAULT_RELEASE_TRACK + '@v1');
  run = s.run();
  run.tellMongo(MONGO_LISTENING);
-  run.waitSecs(2);
+  run.waitSecs(10);
  run.match('localhost:3000');
  run.waitSecs(10);
  s.write('.meteor/release', DEFAULT_RELEASE_TRACK + '@v2');
  s.write('empty.js', '');
-  run.waitSecs(2);
+  run.waitSecs(10);
  run.match('restarted');
  run.waitSecs(10);
  run.stop();