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.
This restriction was preventing the standard-minifier-css from getting
the latest updates to minifier-css. Typically, when publishing
a package outside of a release cycle, I believe we need to manually add
this constraint since `meteor publish-release` normally takes care of it
automatically, however in most cases, I don't believe this should be
(permanently) committed.
I may stand to be corrected, but will find out soon!
This was only intended to be there during the publishing of
`standard-minifier-js` as part of meteor/meteor#8414 and is normally
not necessary as part of the `meteor publish-release` process.
In order to allow for a blank `app.js` which occurs in the case of
a Meteor app using a fully-"package"-based structure with no actual
application code in the top-level. See meteor/meteor#8414 for more.
The error messages which come from UglifyJS tend to be quite cryptic, as
seen in issues like meteor/meteor#8370 or meteor/meteor#8020. The file,
line, and column are provided, however the message is garbled and the
stacktrace long and acutely harrowing. Since these errors are occurring
on automatically concatenated files, even the line number is sometimes
not helpful. Additionally, sourceMaps are not available in production
builds, intentionally. (I wasn't able to access them from
`file.getSourceMap()` or `file.sourceMap` at all.)
In addition to actually providing the name of the encapsulating file,
which provides _some_visibility, this commit implements a parser around
the UglifyJS error which detects the error and location information of
the error, seeks to the line in the concatenated source, reads the
inline filename, and provides it in the output.
Crude, but incredibly helpful in diagnosing this problem until a better
solution is reached.
This should elegantly address the issues described in this comment:
https://github.com/meteor/meteor/pull/8327#issuecomment-280881830
I toyed with the possibility of turning package variables (both imports
from other packages and intercepted "global" variable assignments) into
properties on a shared namespace object, but that would have been a major
breaking change for existing package code, because it would have required
automatically rewriting variable references in package modules.
I made this code asynchronous at first to accommodate the asynchronous
cache API, but walking the graph needs to happen synchronously so that
near-simultaneous dynamic import(...)s do not interleave.
* Update help text to clarify the use of external npm commands
First attempt to improve the help text regarding the external npm commands that can be run directly with 'meteor'.
#8277
Further enhancements could include listing also the "current" available external commands by parsing a ls/dir command or 'meteor npm list -g -depth 0'. If they command is uninstalled between the call of 'meteor help' and 'meteor <external command>' we are not the ones to be blamed but the user instead :)
* Update 'external command' to 'npm command'
* Joining new suggestions and cleaning some redundancy
Included @abernix suggestions (with some variations) to include references to npm and node. Also clarified how to install a npm package and run it afterwards
* Typo
Changed to global context
* Reword description of "other" npm commands
These commands are similar to `node` and `npm`, but we didn't want
them to be confused with `npm command` commands.
* Avoid repetition of `meteor npm install --global`
In particular, if the "main" field of the package.json file cannot be
resolved, then the `resolved` variable will be "missing", which is a
truthy value that silently rejects property assignments. Ugh!
In particular, if the "main" field of the package.json file cannot be
resolved, then the `resolved` variable will be "missing", which is a
truthy value that silently rejects property assignments. Ugh!
* Added in Meteor.loggingOut() and related Blaze helpers.
* Switched loggingIn/loggingOut over to use ReactiveVar; More tests.
* Changed logginInOut helper name to loggingInOrOut.
