The root of the problem was that the es5-ext npm package contains
directories called '#', e.g.
https://github.com/medikoo/es5-ext/tree/master/array/%23
These directory names were being sanitized to '' and thus ignored when
reserving paths in the Builder, which led to reservation conflicts later.
This commit fixes the problem in three different and independently
sufficient ways:
* Use files.mkdir_p instead of files.mkdir when creating parent
directories of written files.
* Replace illegal characters in sanitized paths with '_' instead of ''.
* Allow '#' in sanitized paths (only needs to be escaped in the shell, not
actually forbidden in paths).
Windows began suffering from cryptic ENOTEMPTY and EPERM errors between
1.5-beta.20 and 1.5-rc.0. After a tricky `git bisect` adventure, I tracked
the problem down to my commit b6694b2f5d,
which caused dynamic modules to be written more than once by the bundler.
Though I don't understand exactly why Windows complained in this way, I'm
glad that it did, because otherwise this mistake would merely have been a
performance problem, and might not have been noticed before the release.
No longer using a RegExp when we know what the old file wildcard path
should be, and no longer using Fiber when we can just use a Promise
callback (since all Promise callbacks run in a Fiber).
This method appears to be causing large spikes in memory consumption on
Circle CI during the `meteor --get-ready` preparation step, which often
leads to the test process being killed.
Also added a call in IsopackCache#_loadLocalPackage for good measure.
We're now calling requestGarbageCollection pretty frequently when
we run Node with --expose-gc, but that currently only happens during
Circle CI tests, so I don't think we need to implement the improvements
suggested in tools/utils/gc.js, yet.
Previously: 35f488e140, f6df21ff1e
Now that dynamic modules are part of the manifest that determines which
files are served over HTTP, I'm a bit paranoid about them somehow ending
up as <script> tags in the initial HTML of the application.
This commit adds another safety measure to prevent that, just in case the
boilerplate-generator package for some reason fails to skip items whose
.path starts with "dynamic/" (see my previous commit).
This allows fetching the compiled code of dynamic modules via HTTP,
without generating <script> tags for those resources in the intial
boilerplate HTML of the application.
The URL for a dynamic module should be formed by taking its absolute
module identifier, prepending "/dynamic" and appending "?hash=<version>".
Appropriate version hashes can be obtained from the tree exported by the
meteor/dynamic-import/dynamic-versions.js module, though the hashes are
used only for cache busting, so they could be anything at all.
A good place to do this fetching would be the meteorInstall.fetch
callback, as defined (for example) in meteor/dynamic-import/client.js.
That implementation still uses a WebSocket rather than HTTP, but this
commit will allow us to experiment with HTTP in the future.
Because the code returned for these dynamic modules is wrapped as an
anonymous function expression, you'll need to fetch them using an
XMLHttpRequest, the HTTP fetch() function, or some similar utility, rather
than using a <script> tag, because executing the unmodified code as JS
will likely throw a syntax error.
Now anyone can define meteorInstall.fetch however they see fit, and the
install.js implementation will handle everything else.
This separation of concerns leads to significantly less code, too.
As proposed here: https://github.com/rollup/rollup/wiki/pkg.module
By supporting ECMAScript module entry points for npm packages in Meteor
1.5, we will be well-positioned to do more effective import/export-based
tree shaking in future versions of Meteor.
We can't do the same thing on the server because we can't change how
native Node resolves package entry points based on the "main" field of the
package.json module.
On the other hand, all npm packages have to work in Node using the "main"
field, and client bundles stand to benefit the most from tree shaking, so
this client/server difference should not be problematic.
Note that the "jsnext:main" property is also supported as a legacy synonym
for "module".
* Implement CORDOVA_COMPATIBILITY_VERSION_EXCLUDE and CORDOVA_COMPATIBILITY_VERSION_IOS/ANDROID
CORDOVA_COMPATIBILITY_VERSION_IOS or CORDOVA_COMPATIBILITY_VERSION_ANDROID allows to override compatibility version for a specified platform.
CORDOVA_COMPATIBILITY_VERSION_EXCLUDE provides a way of excluding a certain plugin from compatibility version calculation. You can pass several plugin names with ';'. For example: `CORDOVA_COMPATIBILITY_VERSION_EXCLUDE='cordova-plugin-crosswalk-webview;cordova-plugin-device'`
* Changes after review
Previously, the linker included a "version" hash in each stub entry
corresponding to a dynamic module in the meteorInstall bundle. These stub
entries also contain information about any module identifiers ("deps")
imported by the module, and various other metadata.
This hash was derived from the source code of the dynamic module, instead
of its fully-processed generated code, which created a small risk that the
source hash would remain the same when anything changed in the post-linker
processing logic.
This new implementation uses the same hashes found in program.json
manifest files, which more reliably reflect changes in the actual final
contents of the modules.
Because these hashes are not known at link time, they are now injected as
one blob into the meteor/dynamic-import/dynamic-versions.js module, rather
than appearing in the meteorInstall bundles for their containing packages.
The comma in question: a trailing comma a rest-parameter, within a
function argument's parameter de-structuring:
function a({
a = false,
...b,
}) {
// ...
}
Espree, the parser used by `jsdoc` (used in Meteor docs) previously
allowed this with `experimentalObjectRestSpread` enabled but now throws
an error with the addition of 652990a7bf.
It might have been argued at one point that the trailing-comma could
allow for the easy, future addition of another parameter, ala:
function a({
a = false,
...b,
c = true,
}) {
// ...
}
Having the rest-parameter in the last position is certainly more clear
(it is the "rest", after-all, and there can be only one) but I'm not
going to have that discussion at the cost of docs not deploying!
Instead of fetching a bundle of JavaScript from the server, Cordova apps
include the complete bundle in the installed app, so there's no compelling
reason to allow dynamic module fetching.
The dynamic import(...) function will still work on Cordova, of course.
It will just never have to fetch anything from the server.
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
* Update generated README
- Update node version in generated README file by bundler, according
to version from `.node_version.txt` file
* Use `process.version`
- Minor file linting, one missed semicolon, one unnecessary semicolon
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.
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!
Although we thought the upgrade from `npm` 3.10.9 to 4.1.2 was worthwhile
and safe, this breaking change proved problematic:
https://github.com/npm/npm/blob/latest/CHANGELOG.md#no-more-partial-shrinkwraps-breaking
Specifically, if a Meteor package calls `Npm.depends` in a way that
disagrees with the contents of `.npm/package/npm-shrinkwrap.json` file,
Meteor will create a partial shrinkwrap file in order to install the
correct top-level npm dependencies, but transitive dependencies of the
package will no longer be installed.
This was fixed in Meteor 1.4.2.7 by reverting the upgrade of npm, but
Meteor 1.4.3.1 will keep npm@4.1.2 and fix the consequences.
Inspired by analysis from @danstiner:
https://github.com/meteor/meteor/issues/8225#issuecomment-275044900Fixes#8225, as well as the tests I added in 672c4f338a.
I changed the name of the .meteor-portable file to .meteor-portable-1.json
in order to invalidate previous .meteor-portable files. This naming scheme
will be more sustainable, because we can keep incrementing the version
number whenever we change this logic.
Inspired by analysis from @danstiner:
https://github.com/meteor/meteor/issues/8225#issuecomment-275044900Fixes#8225, as well as the tests I added in 672c4f338a.
I changed the name of the .meteor-portable file to .meteor-portable-1.json
in order to invalidate previous .meteor-portable files. This naming scheme
will be more sustainable, because we can keep incrementing the version
number whenever we change this logic.
