This temporarily reverts back to using @babel/runtime/helpers/* rather
than @babel/runtime/helpers/builtin/*, since some helpers (for example,
`slicedToArray`) were using code patterns that cannot be made to work via
polyfills in older browsers, e.g.
if (Symbol.iterator in Object(arr)) {...}
to test whether `arr` is iterable.
Remove type:"dynamic js" and .map files from `appcache` (app.manifest) since the
dynamic-import package doesn't load dynamic modules from `appcache`, so caching
those files with `appcache` is redundant.
Google's OAuth2 token endpoint
(https://accounts.google.com/o/oauth2/token) returns an
`expires_in` property in its response, which was being stored
internally as `expiresIn`. The `getServiceDataFromTokens`
function would only attempt to work with the `expiresIn` value
if the `tokens` object had a set `expiresAt` property, meaning
the `expiresIn` property was never used. This commit switches
the `expiresAt` check to `expiresIn`.
Fixes#9435.
When sources in the `node_modules` directory are being watched
by a build plugin, if that build plugin is removed while the
Tool is running, the Tool can crash. This is because the Tool
currently see's this situation as an improbable edge case, and
purposely errors out instead of allowing the Tool to continue.
This commit adjusts the Tool to swallow this exception
thereby allowing the rebuild process to continue normally
(and avoiding a Tool crash). Given that the liklihood of this
situation happening is quite low, and the impact of allowing
the rebuild to continue is neglibile (if source files are
no longer handled by a build plugin, app developers will
notice quickly), this seems like an acceptable way forward.
Fixes#8644.
* Stop serving the application manifest from /manifest.json
Meteor currently serves its own manifest file from
`/manifest.json`. This location is not application
configurable, and can conflict with other non-Meteor
defined manifest files, that are already being served
from this location. There isn't really any reason why
Meteor needs to use the `/manifest.json` location, so
this commit moves it to `/__meteor__/webapp/manifest.json`.
Fixes#6674.
* Add PR link to History.md
As demonstrated in https://github.com/meteor/meteor/issues/9276.
This test wouldn't have caught the regression in the previous solution
since the lack of a TTY in the `self-test` test harness caused the tests
themselves to take the path through `shell-server`'s `evaluateAndExit`
logic, which didn't use the `global` scope in the same way as the
interactive shell. That is no longer the case as of e0682c553d.
Much of the infrastructure to run "self test" tests (those which test
core functionality of the `meteor` tool itself) in PhantomJS and
BrowserStack was already in place, though the BrowserStack portion had
been disabled some time ago, though the exact reason isn't entirely
clear.
BrowserStack could play an important roll in Meteor's future as Meteor
works to ensure that the bundle delivered to the client is appropriate
for that client's capabilities, including appropriate polyfills to
implement functionality not natively available in the browser (e.g.
ECMAScript features, SockJS, etc.).
Since tests themselves already keep track of their failure, and the test
list (i.e. the `TestList` class) tracks other concepts of grouped tests,
such as "all tests", "filtered tests", etc. (like a `TestList` class
would!) I believe it makes sense for it to also maintain a collection of
"failed tests"... (in list form, of course!)
This will allow the `Run.runTest` logic to move into `run.js` file without
needing to pass back a separate `failed` variable in the event of a
failure, since that is already being tracked through the `notifyFailed`
facility.
For a while the livedata `reconnect to a different server` test
was failing since the `reverse.meteor.com` host and application
were taken down, but nobody noticed. This is because even
though the test was still enabled, it was configured to swallow
the failure if the connection failed. `reverse.meteor.com` has
been brought back up, so this commit adjusts the test to make
sure it will properly fail if `reverse.meteor.com` goes down
again.
Fixes https://github.com/meteor/meteor/issues/8092.
I previously had thought that a duplicate call to `setRequireAndModule`
encountered in code-path would no longer be necessary after some
consolidation in previous steps of this re-factor, but the test failure
seen here made it clear what was happening:
https://circleci.com/gh/meteor/meteor/12445
Specifically, if a module was imported in a piped command (that is to say,
when no TTY is present and the `evaluateAndExit` code-path is taken), as so:
echo 'import { Meteor } from "meteor/meteor"' | meteor shell
...the `module` and `require` symbols were not set. Conveniently, this is
the environment in effect when the `meteor self-test` suite is ran since
they do not have a TTY.
This moves the `setAndRequire` from the "interactive-only" function into
the general REPL setup and further harmonizes the code.
This is superfluous residue that I inadvertently created when splitting the
existing `startREPL` function into `setupREPL` and `enableInteractiveMode`.
The context is already set in `setupREPL` (to the exact same value as
here) by the time that this occurrence in `enableInteractiveMode` is called.
Addresses feedback from @benjamn.
Rather than copying the `IsRecoverableError` and `isCodeRecoverable`
methods from the Node.js `repl` module source (in order to capture
so-called "Recoverable" errors), wrap the default "eval" function with
our relatively thin logic, thus avoiding the need to continually update
the definition of what's "recoverable" as Node's implementation evolves.
The `meteor build --architecture` help was missing
`os.windows.x86_64`. This commit adds it in and also updates
an out of date comment in the source that referred to there
only being 3 allowed architectures.
