- Ghost has a set of core packages that it is safe to require directly in any file - tpl is one of them!
- This keeps the DI signature smaller and easier to reason about
refs: #13380
- The i18n package is deprecated. It is being replaced with the tpl package.
Co-authored-by: Aleksander Chromik <aleksander.chromik@footballco.com>
refs: #13380
- The i18n package is deprecated. It is being replaced with the tpl package.
- The changed files are under `core/server/api/v2` and `core/server/api/v3`.
refs: #13380
The i18n package is deprecated. It is being replaced with the tpl package.
The files changed are under `core/server/api/v2` and `core/server/api/v3`.
refs: #13380
The i18n dependency is deprecated, it's being replaced by the tpl one.
The `tags.js` files changed is under the following folders:
- core/server/api/canary/
- core/server/api/v2/
- core/server/api/v3/
refs: #13380
- The i18n package is deprecated. It is being replaced with the tpl package.
The files changed is under `core/server/api/v2` and `core/server/api/v3`.
refs https://github.com/TryGhost/Team/issues/694
refs https://linear.app/tryghost/issue/CORE-13
- The controller code is not meant to contain complex business logic. Removed complexity in settings.edit method
- Have brought up to sync v3 controller code to the changes that were done in v4. Didn't touch v2 controller as it had slight API differences, so avoided going on another trip into the unknown
- Migrating v3 controller was pretty straigh forward as it's an exact copy of the v4 one (at least for the methods that were extracted)
refs 70627d84a7
refs 44035fd591
refs https://github.com/TryGhost/Team/issues/477
- When v4 Webhook API was changed removing redundant code v3 API code should've been updated as well. Making this change before extracting logic out into a WebhooksService to have clear chain of why the code that doesn't look the same has been substituted
refs https://github.com/TryGhost/Team/issues/694
refs https://linear.app/tryghost/issue/CORE-10/tackle-integrationsjs
- The controller code is not meant to contain complex business logic.
- Added a test case checking 'PUT' endpoint for integrations to ensure
proper 'NotFound' handling. Found that previous implemenation was
buggy - threw a 500 as 'models.Integration.NotFoundError' that was removed
in previous commit didn't catch a needed error.
refs https://github.com/TryGhost/Ghost/issues/12942
The function signature of this method has changed, and was only updated
in the canary API, this meant that API requests attempting to link a
stripe customer to a member would error for the v3 API.
refs https://github.com/TryGhost/Team/issues/694
- The canary schedules controller was refactored to use newly introduced post-scheduling service in a previous commit. This is a follow up to match v2/v3 controllers as they had identical code to the canary one.
refs https://github.com/TryGhost/Team/issues/694
- Additional try/catch block needed in async/await implementation increased method complexity and broke the complexity linting rule. This is a dirty way to fix the warning. Ideally the implementation should stay with async/await syntax and instead move the custom error handling logic into some different layer. For example we could introduce a separate "stage" in the API framework's "pipeline" where we'd catch and handle in a generic way all of the "unique" types of errors. It would make sense to have a generic handler because this same code happens in labels, member and few more places.
refs baccbb4942
refs https://github.com/TryGhost/Team/issues/694
- The change is here to remove yet another ESLint method complexity error
- The custom error handling complexity was introduced here in a referenced commit without an obvious reason. The specifics of how the "sendTestEmail" method handles errors should not leak out from the method, if there are errors in the response they should be handled internally and the method would uniformly reject with a single error.
refs https://github.com/TryGhost/Team/issues/694
- The code complexity in the email preview's read controller method was breaking the complexity rule in ESLint. To reduce the complexity extracted common parts into mega service
refs https://github.com/TryGhost/Team/issues/694
- async/await has been a standard way to handle async code throughout the codebase. Refactoring it before moving code makes it way easier to reason about similarities between multiple controllers
no issue
- Logic with slightly more complex structure belongs to the service. Extracting it there also show's how little of an API the oembed service should actually expose
- Unquestionably, at some point we need to rework the API code so that we have less stuff everywhere
- However, the max-lines index.js rule exists as a proxy to find index.js files which are not exposing Public API, but rather contain logic
- These 6 cases are all valid index.js files as the expose the Public API of the module
- Therefore, I've added an override and an override notice explaining.
refs https://github.com/TryGhost/Team/issues/949
- Initializing PostsService with almost identical parameters is burdensome, having a single factory method in create instances is far more maintainable
refs https://github.com/TryGhost/Team/issues/949
- The post model handling related to newsletter sending and email recipient filter logic were duplicating across v3/v4(canary) APIs and it made sense to extract it into a posts service.
- This will allow for a central place to handle about to land logic for email_only newsletter handling.
