...with the singular exception of intro.js, where it's part of the
package name, not a file extension.
This is mostly to fix an issue where typescript doesn't want you to
import files with a .ts extension (it will accept .js, but that's super
weird if the file doesn't actually have that extension, and when I tried
it it broke the build for Kenton). Changing the import of .js files is
mainly for consistency.
This also changes some imports to use double quotes (") instead of
single quotes ('); I noticed these while searching for import sites to
replace.
I successfully received a certificate from Let's Encrypt with this, on a Cloudflare-DNS-backed domain.
Currently, there's no configuration UI. You have to poke the database manually. UI will come next.
Integration with Sandcats will require a couple extra steps as well.
Looks like we'd previously extracted db-deprecated.js. Let's keep things
simple during this migration and have main.js be the only file that does
imports purely for side-effects.
This appeared to have a dependency on a particular version of the
content-type package from npm. We can sort that out separately.
Additionally, this has a Meteor package dependency on
fongandrew:find-and-modify. I pinned the version because I vaguely recall this
particular library breaking in the past when we tried to update it and don't
want to deal with that right now either.
This is probably a good candidate for reworking later -- rethinking
how we expose loginServices on client and server seems pretty reasonable
given how little logic the two actually appear to share.
To get the remaining packages into imports, we need to hoist them up in the
reverse order they are loaded. `blackrock-payments` is a leaf in that
dependency tree; let's lift that one first.
We move Blackrock's Stripe dependency into sandstorm's top-level package.json.
We should be able to swap out Npm.require() for plain old imports.
The two asset files are placed in private/, per the Meteor Guide.
The one hitch is that the test for one-shot jobs only works if
the server has been restarted since the last time
advanceTimeMillis() was called. Otherwise, sandstorm rejects the app's
requested date because it is in the past relative to the mocked time,
since the C++ test app isn't using our mock. That still needs fixing.
Maybe we should just be more lenient? Without the check if an app picks
a time slightly in the past, it will just get run as soon as possible,
which seems like reasonable behavior.
The first test is hanging when trying to install the test app, which
is odd since I haven't touched that part. Need to investigate more, but
I should get off the computer and wind down for bed.
Mismatched names/arguments and such.
I have a test app that is successfully injecting a job into the db. Need
to test actually restoring and running still.
This error was introduced in the Mass Transfers PR from last weekend. I was trying to improve the UI when a grain's package was not installed, but the new checks I added didn't consider when the app is registered via `spk dev`.
This makes it easy to mass-transfer grains to another Sandstorm server. A UI lets you choose which grains to transfer, watch the transfer happen, and check and retry any errors.
Previously, when a grain was backed up and then restored, if the restored grain was shared with the same users as the original, the app would not know that they were the same users, as they would be assigned new, different identity IDs. After this change, identities will be remembered as long as the new user shares at least one of the original user's login credentials.
Before this change, if someone shared a grain with you, you opened it, then you deleted it from your grain list, and then later on they shared it with you again, you would get a different identity ID the second time, and so would appear to be a different user within the grain.
After this change, you will regain your original identity ID.
After this change:
- If the free plan allows non-zero grains, then various warnings are shown that the free plan is going away soon.
- If the free plan is set to allow zero grains, then the warnings disappear but the new free plan rules are properly enforced.
The Gateway changed the last-used updated logic, and introduced a bug: the last-used time was only updated after the grain had been open for a full minute (and every minute thereafter). This change fixes it to happen on first open as well.
Fixes#3059
Ian Denhardt
Robert Schmid
Kenton Varda
Drew Fisher
Kenton Varda