We now check `package.json` in order to help make an educated decision
as to whether or not a package has binary dependencies which need to be
rebuilt. In some cases, such as the `npmconf` npm which is included
as a dependency of `flow-router, the `package.json` is invalid (i.e.
empty), and we should silently permit this.
Fixesmeteor/meteor#8427
Because as @hwillson rightfully points out:
> that's what we're really exposing and `connect` themselves refer to the container that holds the defined middleware (the result of calling the `connect()` function) as a connect "app"."
As per the comment on line 653, this appears to be the best (only?) way to let users do things like set up a custom error page to catch app-rendering-time exceptions.
This is a developer experience (DX) change.
In production, the `METEOR_SETTINGS` environment variable is used to
pass parameters which will be available in the `Meteor.settings` within
the app. However, `METEOR_SETTINGS` is ignored when using the
`meteor-tool` itself as in development, environment variables are
often less desirable. Additionally, there would be no reactivity when
changing settings was necessary, instead requiring that the `meteor`
tool be restarted entirely.
On more than one occasion, developers have been confused as to why the
`METEOR_SETTINGS` are not respected in development. To make it more
clear when this is attempted (and clarify that they will _not_ be used),
provide the a clear warning before ignoring the `METEOR_SETTINGS`
variable.
Aims to avoid meteor/meteor#8455.
Keeping track of the latest version for each module identifier was more
important when we were using localStorage, because it helped with
periodically removing unused module sources.
Since the storage limits for IndexedDB are substantially higher than for
localStorage, we can safely keep old versions in the cache, and reap the
benefits if those versions are ever needed again.
Eliminating this extra logic simplifies the caching logic considerably,
and also improves cache read performance.
This reverts commit 027d3e15a7.
This optimization was not safe in all browsers. In particular, Firefox
complained about requests against inactive transactions.
If import(...) is called multiple times in quick succession, these changes
should allow cache.checkMany to avoid the overhead of creating multiple
IndexedDB transactions.
This prevents __dynamicImport from blocking other method calls made by the
application, but introduces the possibility that __dynamicImport method
results could be delivered out of order, which is now handled in the
fetchMissing function.
I was able to achieve tolerable performance by using only one (read-only)
transaction for each cache.getMany call, and only one (read+write)
transaction for each cache.setMany call.
Apply the check for a SyntaxError indicating an incomplete command only
to the ECMAScript translation and parsing of a command and not to the
execution, following the example of Node's defaultEval function.
Fixes#8290.
