build-sandstorm fails with App exceeds uncompressed size limit of 1 GiB and nothing else. Because Sandstorm refuses to pack, no .spk is written, so there is no artifact to open and no list of what filled it.

The first attempt at that added a size report before meteor-spk pack, and the next run showed it printing nothing at all:

  --- packing (Sandstorm refuses over 1 GiB uncompressed)
  Building Meteor app...

meteor-spk pack is what BUILDS the Meteor app - Building Meteor app… comes after it starts - so .meteor-spk/deps and .meteor-spk/bundle do not exist until it has run. The report was measuring two directories that were not there, found neither, and skipped both silently. A diagnostic that runs before the thing it diagnoses says nothing at all.

The sizes are taken AFTER pack now: on failure, where they are the whole point, and on success, where the headroom against 1 GiB is worth knowing before the next thing is added. du -shL DEREFERENCES, because deps is a symlink to the tree sandstorm-src/build-deps.sh assembles and a plain du -sh on a symlink reports the link rather than the gigabyte behind it. The bundle’s server packages are listed separately, because they are the part every other bundle prunes.

And one bounded RETRY, which is an attempt at the fix rather than more looking. meteor-spk pack runs npm install inside the bundle’s programs/server - that is where tar@6.2.1 and node-gyp’s tree come from in the log - and the Sandstorm leg is the only one that never removes them afterwards. prune-build-only-modules.mjs drops 83 of 120 packages everywhere else, and nothing in a packed app runs any of them. Whether it is enough turns on something no log has answered yet: does a second pack REUSE .meteor-spk/bundle, or rebuild it and undo the prune? Both answers are useful and neither is worse than the hard failure that is there now - if it rebuilds, the second failure is identical and the log says the prune was undone; if it reuses, the .spk packs. It runs once, only after a failure, and only if the bundle is actually there.