These changes pave the way for incrementally converting the implementation
of Meteor's command-line tool to TypeScript, which should have profound
benefits for self-documentation via types, as well as substantially
improving navigability and approachability for community contributors.
Just imagine being able to auto-complete the fields of the various
File-like classes currently floating around the codebase, instead of
having to track down their implementations every time. TypeScript was
designed with large projects like Meteor in mind, and it seems
increasingly irresponsible to forgo the benefits of a type system by
relying on the expertise of a few core contributors who know the codebase
inside and out. I am one of those few people, and I am very excited to
have the assistance of a type system, so I can only imagine how
transformative and empowering it will be for everyone else.
If you've ever wanted to get involved in core Meteor development, picking
a few meteor/tools modules to convert to TypeScript is a great way to get
to know that part of the codebase, while also making things easier for
everyone else who interacts with that code in the future.
Because we already compile meteor/tools using Babel, it makes the most
sense to use Babel's @babel/preset-typescript to compile .ts files:
https://babeljs.io/docs/en/next/babel-preset-typescript.html
Using Babel also means we get to keep all of our current advanced
compilation strategies, such as using Reify to compile module syntax:
https://www.npmjs.com/package/reify
Since we're using Babel, the meteor/tools/tsconfig.json file exists mostly
for the benefit of external tools like VSCode, rather than as a source of
truth for compilation behavior.
Despite our existing convention of including explicit .js file extensions
when importing modules, TypeScript and VSCode strongly encourage omitting
the file extension, so the import can be resolved to a .ts file in
development or a .js file when compiled. Although I find this ambiguity
somewhat unfortunate, it makes sense to follow community norms, at least
until Node.js begins supporting .ts modules by default.
The promise package needs a weak dependency on this package (on the
server) because meteor-promise saves a reference to Fiber.yield, so we
need to have wrapped Fiber.yield with noContext before that happens.
The optimism package no longer knows anything about Fibers, but it does
export various helpers for managing execution contexts, one of which
(noContext) allows us to censor the current context for the duration of a
function call. By wrapping Fiber.yield with noContext, we keep distinct
Fibers from accidentally registering cache dependencies on one another.
Using the `isMaster` command instead of checking the replica set member state is more reliable because a node can be a primary without being writable.
Fixes#10381 and #9026.
Now that we've moved into the release candidate phase, there will be no
more new features added to Meteor 1.8.1, and all remaining effort will be
focused on fixing bugs.
Please test the release candidate if you have time, by running the
following command in any application directory:
meteor update --release 1.8.1-rc.0
This reverts commit 95a1f54cce.
Although at first this commit seemed like a nice optimization, after
digging into #10496 I was reminded that the main bundle includes the paths
and hashes of available dynamic modules, so rebuilding the main bundle is
important even when only dynamic modules have changed.
Many thanks to @arggh for testing 1.8.1-beta.20 and putting together the
https://github.com/arggh/meteor-bundler-issue reproduction.
Should fix#10496 and #10494.
Adding @zodern as a collaborator with write access (including
triage/review), based on contributions that demonstrate deep understanding
of the meteor/meteor codebase: #9887, #10399, #10452, #10453, #10454
Also updated other parts of CHANGELOG.md to reflect 2019 realities.
Tests have started failing for reasons that may be related to puppeteer's
Meteor process management: https://circleci.com/gh/meteor/meteor/31035
Since I can't identify any other possible causes, using the same version
of puppeteer that other tests use (e.g. modules, dynamic-import) seems
like a reasonable first step.
Also updated puppeteer in tests/apps/app-config/package-lock.json to
version 1.6.2 (was 1.3.0), in an attempt to fix some unhandled promise
rejection warnings: https://circleci.com/gh/meteor/meteor/31063
