refs https://github.com/TryGhost/Toolbox/issues/358
- Error handling should be done as close to the place that knows how to handle them. It's a catch-all block which doesn't add any logic, so does not really make sense to have that extra code in general "init" method which ideally should be just a whole bunch of calls with no extras.
refs https://github.com/TryGhost/Toolbox/issues/354
- these READMEs were migrated over from when each package was in a
different repo
- they also assume you're going to be publishing the packages because it
mentions install instructions
- only a few of them contain custom content
- this commit deletes the majority of these files because they're now
not useful
- any that contained other instructions have been cut down
refs https://github.com/TryGhost/Toolbox/issues/354
- these repository links made sense when they were in different repos
and published to NPM but we don't publish these packages any more
- this commit deletes those keys from the files
- these were copied over during the monorepo conversion but we're not
going to be publishing these packages so the top-level LICENSE file
covers all packages here
- we're going to be pinning all dependencies within the monorepo
- this shouldn't change anything anyway because we're using the same
version across all packages
- these packages are split apart for local development, but will be
bundled into Ghost when publishing
- therefore, these packages won't be published so we are resetting the
versions to make them cleaner
refs https://github.com/TryGhost/Team/issues/1490
With multiple newsletters, paid members can choose their newsletter preference at the time of signup via Portal. This change handles the newsletter preference via stripe checkout metadata and stores it against the member on completing signup.
no issue
- When Ghost is running in a test environment, it is configured with an invalid Stripe key that looks like `sk_test***`. In this case the migrations try runnig creating request to Stripe, which fail. The failures pollute the output, which makes other valid errors lost.
- An example of such error log is following:
```
Invalid API Key provided: sk_test_******ripe
----------------------------------------
Error: Invalid API Key provided: sk_test_******ripe
at res.toJSON.then.StripeAPIError.message (/home/naz/Workspace/Ghost/Ghost/node_modules/stripe/lib/StripeResource.js:214:23)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
```
- There doesn't seem to be a good reason to do migrations in the test environment. Skipping them as a special case to fix the output pollution problem seems like a right solution
refs https://github.com/TryGhost/Team/issues/1437
- This enables this package to declare the version of all its dependencies
- It avoids using a different `@tryghost/domain-events` version, which ends up creating a new underlying EventEmitter than the one used with the other packages in this monorepo.
- The long term fix to avoid to have multiple EventEmitters is to make domain-events an injected dependency, so that it's only a dependency of Ghost core.
refs https://github.com/TryGhost/Team/issues/1289
We had a bug where Tiers would have a name of 'Default Product', and a
Stripe Product would be created with the same name. This migration will
fixes those broken Stripe Products
refs https://github.com/TryGhost/Toolbox/issues/203
- without `--all`, c8 ignores files that should be included in the
coverage score but aren't used in tests
- this means we have artificially high scores in places where this isn't
used
- this commit adds `--all` where previously missing
- where this fails `--check-coverage`, that has been removed for now
refs https://github.com/TryGhost/Toolbox/issues/214
- After disconnecting Stripe API the `_configured` flag stayed as `true`, causing behaviors as if Stripe was still connnected.
- The `api.configure` method was never reachable when disconnecting Stripe API, thus causes hanging "configured === false" state inside of the StripeAPI wrapper
refs https://github.com/TryGhost/Team/issues/1374
We cannot update payment details for members which we don't know about,
so returning and giving a successful response to Stripe is the correct
thing to do.
