When publishing a core package, you’re allowed to omit version numbers in package.js. With this change, we determine the correct versions of all the dependent packages based on the current checkout, and we send them to troposphere (instead of core packages having “null” constraints on their dependencies).
We throw an error if you have any missing version constraints on your package dependencies and you are not using versionsFrom or publishing a core package from a checkout.
We’ve already fixed this (no constraints on core package deps) retroactively in troposphere.
It speeds up the constraint solver by orders of magnitude when publishing a package.
This timeout was designed for a very specific case (hit stop during a
hot code push, come back to the page later and you don't expect your
session state to still be there), but it's not clear what length of time
is right for that, nor whether it's even what users expect (and if there
should be a timeout, it probably varies from package to package
depending on what type of data the package is storing in sessionStorage
-- e.g. for OAuth logins, 30 seconds is way too short of a timeout).
Fixes#2696.
This timeout was designed for a very specific case (hit stop during a
hot code push, come back to the page later and you don't expect your
session state to still be there), but it's not clear what length of time
is right for that, nor whether it's even what users expect (and if there
should be a timeout, it probably varies from package to package
depending on what type of data the package is storing in sessionStorage
-- e.g. for OAuth logins, 30 seconds is way too short of a timeout).
Fixes#2696.
When you set ROOT_URL_PATH_PREFIX, source maps are not found because the server serves them at a different path from where the client looks for them.
I don’t understand this code super well, but based on what’s reported in issue #2627, the new code seems strictly more correct than the old code.
When you set ROOT_URL_PATH_PREFIX, source maps are not found because the server serves them at a different path from where the client looks for them.
I don’t understand this code super well, but based on what’s reported in issue #2627, the new code seems strictly more correct than the old code.
This code was factored out a long time ago, but got duplicated by
accident in a merge conflict resolution (611298f).
Also lay some groundwork for a unit test.
These were broken by the Template.foo.bar -> Template.foo.helpers({ bar:
... }) transformation. `fields` is a property on the template object,
not a helper.
Parse as decimal (which means you can't specify --parent-pid in hex,
that's fine). And convert back to string to check that the whole string
was parsed as an int (i.e. "123foobar" should not be converted to
"123").
Thanks Slava and Avital.
If you pass "--parent-pid foobar", then we immediately log an error
message and exit. This check happens via `parseInt` rather than testing
for exceptions in `process.kill(parentPid, 0)` because `process.kill`
converts its pid argument to an integer, so `process.kill('foobar', 0)`
returns true just as `process.kill(0, 0)` does.
