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.
Before this fix, we were producing tarballs that npm 'tar' couldn't
untar if the first file inside the top-level directory was not
writeable. (Which was indeed the case since the unipackage -> isopack
change, which resulted in isopack.json being the first file in built
package tarballs.) See comment for more explanation.
Summary:
The `node-inspector` NPM package was added to the dev_bundle by this
recent commit: 64a624ae5c
Task: https://app.asana.com/0/15750483766338/16241466809965
Test Plan:
Add `debugger` statements to server code, run `meteor debug`, visit the
node-inspector URL in a browser, continue the application, and verify that
the debugger stops at the `debugger` statements that were set.
Reviewers: nim, slava, emily, avital, dgreenspan
CC: sashko
Differential Revision: https://phabricator.meteor.com/D827
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.
