This is another way to fix the bug I previously fixed by passing
options.allowSyntaxError to optimisticReadJsonOrNull.
To reproduce the bug (and/or verify that it is fixed), run the following
commands in a terminal:
rm -rf meteor/packages/npm-mongo/.npm
meteor/meteor --get-ready
Before these two commits, optimisticReadJsonOrNull would throw a
SyntaxError when reading one of the .meteor-portable files because an
asynchronous write to the same file had not yet finished.
Tests were broken by the new dependency on the babel-runtime npm
package, but fortunately all those tests run `meteor --prepare-app`
whenever an app is created by a self-test, so this change should fix
most of the breakages.
At this point, the only dependencies installed in this way are
babel-runtime and meteor-node-stubs, but that set of packages will
expand in the future as we move more dependencies to npm.
In light of issues like #7956, I would very much like for app developers
to be responsible for providing node_modules/babel-runtime, and for the
Meteor babel-runtime package to stop attempting to implement a subset of
the helpers.
Set METEOR_DISABLE_FS_FIBERS=false to un-disable files.* fibers if you
suspect this commit has introduced a problematic difference in behavior.
cc @veered
By removing the `--allow-superuser` and `--unsafe-perm` arguments before springboarding, it prevents older versions of Meteor from objecting to its use. Catching it at the highest level should be sufficient to discourage root usage as intended in meteor/meteor#7821
Intended to fix... meteor/meteor#7959
This is important for `meteor npm`, since we don't parse or pass through
Meteor-specific command-line arguments when running `meteor npm`.
When METEOR_UNSAFE_PERM is set, its value is now propagated to any npm
commands via the NPM_CONFIG_UNSAFE_PERM variable.
Helps with #7959.
Follow-up to #7821.
Note that the value of the "main" property must include the ".node"
extension explicitly, because I have yet to encounter an npm package with
a native "main" module that omits the ".node" extension, and I am loathe
to start calling files.stat(id + ".node") uselessly for every single
missing module.
Fixes#7947.
Meteor 1.4.2 has been mostly focused on improving rebuild times, but what
ultimately matters is the time from changing a file to being able to make
requests against the restarted server, and any code that runs before
server startup should be considered part of that critical path.
If you have a lot of packages, and they do non-trivial work on startup,
this commit should give you much better insight into where time is spent.
Credit to @stubailo for pushing me to provide Meteor developers with
better profiling tools, and thanks to @veered for this specific idea.
Note: because tools/tool-env/profile.js is now loaded as-is by boot.js,
certain ECMAScript features are off-limits, e.g. ...rest params.
This test has been the primary source of test suite unreliability in
recent weeks. By marking it "slow" I'm effectively disabling it on
CircleCI, which I think is acceptable because (1) it is, in fact, quite
slow; (2) it passes locally on Linux; and (3) it depends on the timing of
file change notifications, which is a recipe for test flakiness due to the
general non-determinism of file watching, but not necessarily a sign of a
broken developer experience.
Like other "slow" tests, I will keep running this test locally via
meteor self-test --slow 'javascript hot code push'
as part of the manual QA testing that we do.
It's a shame that Pathwatcher issues this warning using console.error,
without taking any verbosity options into account:
https://github.com/atom/node-pathwatcher/blob/7ef76e5dfd/src/main.coffee#L53
Fortunately, I believe I've identified the underlying reason why this
happens, which may help resolve the following issue:
https://github.com/atom/node-pathwatcher/issues/98
If all goes well, I'll submit an upstream pull request.
I've also reinstated an old file watching test that I mistakenly removed
when I attempted to switch to chokidar instead of pathwatcher.
This is a bit different from the previous strategy of invalidating
optimistic functions for specific npm package names.
Now, whenever we make changes to the contents of a specific node_modules
directory, or whenever the developer independently modifies an app's
node_modules directory, all optimistic results derived from paths
contained within that node_modules directory will be marked as dirty, and
thus may need to be recomputed.
This strategy prioritizes starting fewer watchers (just one per
node_modules directory) while still allowing npm packages to be added or
removed while the app is running:
https://github.com/meteor/meteor/pull/7668#issuecomment-255120373
The drawback is that changes within subdirectories of node_modules will
not be detected until the server is fully restarted, but that seems like
an acceptable tradeoff, since npm packages change much less often than
application code.
