The excludeFile API was introduced in meteor-babel@7.8.1:
bfded57377
Modules that are evaluated before meteor-babel/register is configured
should not be transformed by meteor-babel, even if they are imported again
later, after meteor-babel/register has been configured.
If my analysis is correct, this change should prevent the dreaded
Must export a default export when using ES6 modules.
error, as seen most recently in
https://travis-ci.org/meteor/meteor/builds/638030190
and https://circleci.com/gh/meteor/meteor/40863.
Unfortunately, this conversion triggered an error due to one of the
shortcomings of the Babel implementation of TypeScript:
SyntaxError: /tools/tool-env/profile.ts: Namespace not marked type-only declare. Non-declarative namespaces are only supported experimentally in Babel. To enable and review caveats see: https://babeljs.io/docs/en/babel-plugin-transform-typescript
278 | }
279 |
> 280 | export namespace Profile {
| ^
281 | export let enabled = !! process.env.METEOR_PROFILE;
282 |
283 | export function time<TResult>(bucket: string, f: () => TResult) {
at File.buildCodeFrameError (/Users/ben/meteor/dev_bundle/lib/node_modules/@babel/core/lib/transformation/file/file.js:261:12)
at transpileNamespace (/Users/ben/meteor/dev_bundle/lib/node_modules/@babel/plugin-transform-typescript/lib/namespace.js:25:25)
at PluginPass.TSModuleDeclaration (/Users/ben/meteor/dev_bundle/lib/node_modules/@babel/plugin-transform-typescript/lib/index.js:271:32)
at newFn (/Users/ben/meteor/dev_bundle/lib/node_modules/@babel/traverse/lib/visitors.js:193:21)
at NodePath._call (/Users/ben/meteor/dev_bundle/lib/node_modules/@babel/traverse/lib/path/context.js:53:20)
at NodePath.call (/Users/ben/meteor/dev_bundle/lib/node_modules/@babel/traverse/lib/path/context.js:40:17)
at NodePath.visit (/Users/ben/meteor/dev_bundle/lib/node_modules/@babel/traverse/lib/path/context.js:88:12)
at TraversalContext.visitQueue (/Users/ben/meteor/dev_bundle/lib/node_modules/@babel/traverse/lib/context.js:118:16)
at TraversalContext.visitMultiple (/Users/ben/meteor/dev_bundle/lib/node_modules/@babel/traverse/lib/context.js:85:17)
at TraversalContext.visit (/Users/ben/meteor/dev_bundle/lib/node_modules/@babel/traverse/lib/context.js:144:19)
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 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.
Fixes#10073, per
https://github.com/meteor/meteor/issues/10073#issuecomment-405290391
While thinking about this bug, I realized that sending IPC messages to
specific packages in the server process was much less flexible than
sending messages based on an arbitrary topic string, since the topic
string approach allows both `autoupdate` and `dynamic-import` to listen
for the same message.
The topic string approach calls for a listener interface like
`onMessage(topic, callback)`, which elegantly replaces the previous
approach of requiring packages to export a single `onMessage` function.
However, because the `meteor` package does not have access to the module
system, implementing the `onMessage` listener interface in the `meteor`
package would have required exposing an API like `Meteor.onMessage(topic,
callback)`, which has an unpleasant global smell to it. Instead, the
`onMessage` function should be explicitly imported (using the module
system) from a less-generically-named package.
Since I knew I was going to have to move the message dispatch logic out of
the `meteor` package, I decided to create a new package called
`inter-process-messaging` to implement the parent/child components of the
IPC system.
By my calculations, the sum of the sizes of the individual isopackets was
152MB, and the size of the combined isopacket is now just 36MB. That
remarkable difference goes to show how much duplication of transitive
dependencies was happening before this change.
That's a savings of 116MB for the (uncompressed) size of the meteor-tool
package. In Meteor 1.5.x, the meteor-tool package is about 544MB, but in
Meteor 1.6 it's considerably smaller: 373MB. In other words, this change
should reduce those sizes to 428MB (-21%) and 257MB (-31%), respectively.
Related to https://github.com/meteor/meteor/pull/8728#issue-232369984,
though these changes apply only to the meteor/tools codebase. We still
need to make similar changes to the babel-compiler package so that
application code will benefit.
The assumption that we're using Node 8 also allows some simplifications to
the runtime polyfills that we use.
Meteor 1.4.2 has been mostly focused on improving rebuild times, but what
ultimately matters is the time from changing a file to being able to make
requests against the restarted server, and any code that runs before
server startup should be considered part of that critical path.
If you have a lot of packages, and they do non-trivial work on startup,
this commit should give you much better insight into where time is spent.
Credit to @stubailo for pushing me to provide Meteor developers with
better profiling tools, and thanks to @veered for this specific idea.
Note: because tools/tool-env/profile.js is now loaded as-is by boot.js,
certain ECMAScript features are off-limits, e.g. ...rest params.
Now that the blaze submodule is mounted inside the packages/non-core/
directory, it appears that we no longer have to mention it explicitly in
the localPackageSearchDirs array.
