This used to "work" (somewhat accidentally) before we got stricter about
which `node_modules` directories `Npm.require` can search:
971d2b1272
This commit should fix the problem with `juliancwirko:postcss` reported
here: https://github.com/meteor/meteor/issues/9094#issuecomment-331964596
Note that this only works for `Npm.require` when called during the build
process, not at application runtime. Use ordinary `require` for that.
Although this flag allows the build process to be more aggressive about
collecting garbage, it has also been a source of several problems in
Meteor 1.5.2 and Node 4.8.4, from increased segmentation faults during
garbage collection to extreme slowness in rebuilding local packages.
We still use this flag in the Meteor 1.6 betas, where it appears to cause
no problems. For Meteor 1.5.x, however, I think we need to prioritize
development reliability over memory efficiency, for now.
Fixes#8648.
Fixes#9094.
This reverts commit 6b80cdaea4.
I'll re-introduce this commit to the release-1.6 branch so it doesn't
interfere with 1.5.x releases on the active `devel` branch. The PR
should have likely targeted the 1.6 branch anyhow.
Calling unwatchFile may result in stopping the watcher before watchFile is
called, which then restarts it. This temporary stoppage appears to cause
change events to be missed sometimes. In particular, preventing this
stop/start with the acrobatics in this commit seems to fix recent
compiler-plugins.js test failures.
Since 8c70716954, optimistic file watching
uses far fewer file descriptors, so the original motivation of setting
this environment variable no longer holds.
* When awaiting Mongo, wait until the heartbeat has pulsed after election.
> Prologue: A heartbeat is used amongst members of a MongoDB replica set
to poll the status of said members.
When we are initiating a new replicaset for the test Mongo server, the
replicaset is not fully prepared to accept writes until the voting
members have negotiated and propagated their decision about who is the
"primary" to all members involved. This seems to be delayed by almost
_exactly_ the default heartbeat interval, which is 2000ms.
The heartbeat interval is marked as an "internal only" property in Mongo
so I was hesitant to lower it. It's also a new property in Mongo 3.2
which might explain why this cropped up a while ago.
I believe this heartbeat delay is the only explanation for why the
`rs.status()` (i.e. `replSetGetStatus`) believes it is ready before the
`mongod` has actually printed "transition to primary complete" to the
log.
Fixesmeteor/meteor#9026.
* Replace addl. variable occurrence with the new `firstMemberState` var.
* Fix bug #5665: add DDP.onReconnect(), deprecate conn.onReconnect
Deprecate use of `connection.onReconnect = func`. Instead, a new
`DDP.onReconnect(callback)` method should be used to register callbacks to call
when a connection reconnects. The connection that is reconnecting is passed as
the only argument to `callback`. This is used by the accounts system to relogin
on reconnects without interfering with other code which uses
`connection.onReconnect`.
* Adjust History entry, package versions, code cleanup
* Fix issues with Infinity based login token lifetimes
Several areas of the Accounts system are using the current
login token expiration millisecond limit for different
`Date` based calculations. When `loginExpirationInDays` is set
to `null`, and the Accounts system uses an expiration limit of
`Infinity`, these `Date` based operations fail, since
`Infinity` can't be converted to a `Date`.
These changes replace the use of `Infinity` with a far future
fixed date representation, that's used when
`loginExpirationInDays` is set to `null`.
Fixes#9066.
* Small comment typo
* Remove unnecessary comment
Some simple messaging changes to the README to account for the fact that Meteor uses not just "pure" JavaScript, but modern JavaScript.
Additionally, link to the React and Angular tutorials, not just Blaze.
The visualizer seems to have stopped working recently if you reinstall its
npm dependencies without using the existing npm-shrinkwrap.json file,
likely due to changes in indirect dependencies.
The good news is that the package now has far fewer npm dependencies.
However, since the sunburst.js module imports d3-collection explicitly, we
should definitely be depending directly on that package.
cc @abernix
This is another way of addressing the problem I attempted to fix with
f34c5ec926 earlier today.
Apparently, older versions of compiler plugin-registering packages such as
standard-minifier-css and templating-compiler still depend on older
versions of the meteor package, which may still use path.join to import
fibers/future. This can be fixed by republishing those packages, as I did
in 917b01ac5f, but I'd prefer not to
republish every compiler plugin package.
Fortunately, we can also solve the problem by being more tolerant in the
implementation of Npm.require, which is what this commit does.
Since all Meteor packages implicitly depend on the meteor package, it
appears packages that register compiler plugins may need to be republished
in order to benefit from f34c5ec926, or else
the `Cannot find module "fibers\\future"` error may occur on Windows.
This misunderstanding of CommonJS module identifiers goes back to 2012:
8f83b2c32e
In Node, CommonJS module identifiers are always delimited by forward
slashes, even on Windows. Using path.join to abstract away the choice of
platform-specific delimiter is therefore pointless.
While this usage of path.join was always pointless, it was also mostly
harmless until #9095, when we stopped falling back to Node's native
`require` function to handle e.g. `Npm.require("fibers\\future")`. That PR
made the misuse problematic on Windows, so this commit fixes that.
A fix to the dynamic-import code to correctly detect modules version.
Without this fix dynamic-import can't detect correctly modules versions
which breaks the dynamic-import cache functionality.
Ever since Meteor 1.3 first introduced a module system based on something
other than `Npm.require`, we've continued throwing missing module
exceptions that refer to `Npm.depends` and/or `Npm.require`, even if the
developer called `require` or used an `import` declaration. This commit
fixes that, so that all missing module exceptions look like 'Cannot find
module "module/name"'.
I also noticed recently that `Npm.require` is capable of returning modules
installed in `node_modules` directories completely outside the app, which
is bad news for development/production reproducibility. Fixed that too.
CC @hwillson who has spoken of deprecating `Npm.require` entirely, and
just using `require` everywhere, instead.
