mirror of
https://github.com/meteor/meteor.git
synced 2026-05-02 03:01:46 -04:00
77ed148614
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.
Uninteresting files that run on tool's startup (set up profilers, transpilers, etc) and exit (clean up code, flush the output).
ES2015 compilation for tool
There are two different configurations of Babel for the tools code:
- local development from git checkout
- running in production from a release
In the first case, it is enough to register Babel's hook for require. For the
latter, this hook should be removed (#RemoveInProd) and the files should be
explicitly compiled.
The listing of Babel-compiled files can be found in isopack.js, the
Isopack#_writeTool method runs all the preprocessing when tools files are
copied for a release package.