Best I can tell, the major version portion of Chromium versions has always
tracked all the way through to Chrome Canary, Dev and Stable releases.
Since we observe the major version of Chrome in terms of identifying it as a
"modern browser", it seems to make sense to treat "Headless Chrome" and
Chromium in the same regard.
Interestingly, when the same Chrome as we all use on our machines is run
with the `--headless` flag, it switches its `navigator.userAgent` to
`HeadlessChrome/`, rather than `Chrome/`.
This was initially problematic since the `useragent` npm we use for parsing
user agents didn't understand this designation, however, with the update of
`webapp`'s `useragent` npm in 058351b7, `headlesschrome` will now have its
version available from `WebAppInternals.identifyBrowser`, so we can
accurately identify it and serve it the modern bundle.
Previously, while the `useragent` package was able to parse the User-Agent
for so-called "Headless Chrome" and generate a family of "HeadlessChrome",
it was unable to parse out the individual portions of the version number
(e.g. major, minor, patch).
For example, the following User-Agent (herein referred to as `userAgentAbove`):
```
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/69.0.3497.100 Safari/537.36
```
Previously resulted in:
```
> require('useragent').lookup(userAgentAbove);
{
family: 'HeadlessChrome',
major: '0',
minor: '0',
patch: '0',
/* ... */
}
```
With the newer version of `useragent`, these are now properly extracted and
set which will enable Meteor to treat Headless Chrome the same as Chrome in
a follow-up commit. Now:
```
> require('useragent').lookup(userAgentAbove);
{
family: 'HeadlessChrome',
major: '69',
minor: '0',
patch: '3497'
/* ... */
}
```
After @nathan-muir's PR #10053, we did not publish a new version of the
diff-sequence package, which would have contained DiffSequence.diffMaps.
I honestly have no idea why #10320 did not manifest before now, but
publishing these changes seems to fix it.
With the introduction of lazy compilation in Meteor 1.8, calling
inputFile.addJavaScript({
...
hash: inputFile.getSourceHash(),
...
}, function () {
return compiler.processFilesForTarget(inputFile);
});
becomes problematic, since inputFile.getSourceHash() is usually different
from compiler.processFilesForTarget(inputFile).hash, because the latter is
computed from the compiled code, whereas the former is computed from the
source code.
For example, when we use file.hash to cache imported module identifiers in
ImportScanner#_findImportedModuleIdentifiers, we really need to be using
the hash of the compiled code, since a single source module can be
compiled in different ways. If we cache based on the source hash, there's
a risk of reusing the scanned imports from the web.browser version for the
web.browser.legacy version, which can lead to all sorts of problems that
are only apparent in legacy browsers.
The quick fix is easy enough: BabelCompiler can simply stop including a
hash in the eager options to inputFile.addJavaScript. This fix can be
published as a minor update to the babel-compiler and ecmascript packages.
The remaining changes in this commit add another layer of defense against
this problem, by ignoring any hash options provided by compiler plugins,
in favor of simply computing the hash from the compiled data buffer.
These additional changes will become available in the next release of
Meteor (likely 1.8.1).
While strictly speaking more characters are allowed, they are not usable in a shell except for uppercase / digits / underscore.
( https://stackoverflow.com/a/2821183 )
`autoupdate` and `reactive-dict` are using the `reload` package if it's available. To ensure that all packages are loaded in the correct order, these dependencies must be explicit.
- Return type of onMigrate callback should be an array.
- onMigrate callback can be invoked many times until all components
are ready to migrate.
- DDP negotiation failures should always migrate immediately.
