refs https://github.com/TryGhost/DevOps/issues/50
- when creating a TS config in our `eslint-plugin-ghost` dependency, I
only extended the recommended config, which left out a lot of
stylistic things we used to enforce in JS
- this fixes that by bumping the dependency to a version which extends
those shared configs, and fixes all the code that currently goes
against those rules
refs https://github.com/TryGhost/Arch/issues/86
- When PostEditedEvent data contains no visible changes we can skip the matching collections update process alltogether. Each call to `updatePostInMatchingCollections` creates a transaction in addition to fetching all collections. There's no need to process anything when there are no relevant changes in the post edit!
refs https://github.com/TryGhost/Arch/issues/82
- Collections logs are too verbose causing noise.
- Moved some of the logs to use "debug" for now and made summarized logs for the information that we still need while collections code is actively monitored. The event info logs can be removed once we are passed the active phase of rolling out the collections feature
refs https://github.com/TryGhost/Arch/issues/77
- During initial development we have missed to support collections update when tags are added to posts in bulk. It's especially valid usecase since we can define automatic collection with a filter containing not yet existing tags.
refs https://github.com/TryGhost/Arch/issues/47
This ensures that we only have collections which have a valid filter in terms of
- Valid NQL string
- Uses only properties which are valid to filter on
- Only has an empty filter in the case of the "latest" collection
refs https://github.com/TryGhost/Arch/issues/16
- Without an extra await in the update function the passed in transaction would complete before all updates had a chance to run within this transaction.
refs https://github.com/TryGhost/Arch/issues/16
- When posts produce PostsBulkFeaturedEvent/PostsBulkUnfeaturedEvent the collections having a featured filter should update the posts belonging to them.
refs https://github.com/TryGhost/Arch/issues/16
- When posts produce PostsBulkUnpublishedEvent the collections having a published_at filter should update the posts belonging to them
refs https://github.com/TryGhost/Arch/issues/16
- When the bulk destroy is done on posts Collections need to know about the update and remove the stored posts from collections.
refs https://github.com/TryGhost/DevOps/issues/50
- we should default to keeping the rule on and so I've excluded lines
that currently use `any` to avoid the need to go and fix them all up
closes https://github.com/TryGhost/Arch/issues/62
Because there are many ways in which filters can rely on tags, we will just
recalculate all automatic collections for now, rather than attempting to do
optimised updates.
The PostRepository type was using `any` (an anti pattern) rather than
`PostCollection`, and we had optional properties, which are not really
optional. This cleans up the types and updates the tests alongside them.
refs https://github.com/TryGhost/DevOps/issues/50
- `react-app` comes from `eslint-config-react-app`, which is a CRA package
- we're moving away from that so this commit switches the linting over
to a more recently updated plugin
- once that was removed, we started using a newer version of
`@typescript-eslint/eslint-plugin`, so there were plenty of
updates/exemptions to make
refs https://github.com/TryGhost/Arch/issues/60
This will be used to update collections when a tag is deleted. Like the Post
events this should not be in the collections package, instead we should have
these as part of the tags and posts packages. These packages don't exist right
now, so I'm following the existing pattern.
refs https://github.com/TryGhost/DevOps/issues/50
- this switches the .eslint configs from `node` to `ts`, which is a new
config to support eslint for TypeScript
- also makes minor changes to adhere to these new rules
refs https://github.com/TryGhost/Arch/issues/46
- Similarly to post filters, collection filters now support both 'tag' and 'tags' nql filter keys when defining a filter for related tag slugs. For example, both `tag:avocado` and `tags:avocado` would both be valid collection filters that would filter by the same 'slug' property of the tags assigned to a post.
- Along with these changes had to rework the tags property of the collection posts to match the shape used in post resources. Moved from:
`tags: ['bacon', 'broc']`
to
`tags:[{slug: 'bacon'}, {slug: 'broc'}]`
refs https://github.com/TryGhost/Arch/issues/16
- Some of the methods became unused due to moving the posts handling out of the collections service and cleaning up the event handling system.
refs https://github.com/TryGhost/Arch/issues/16
- Using the API directly on the repository level prevented us from ensuring collection consistency through transactions.
- This change migrates the PostsRepository to use Bookshelf model layer directly, which also allows to put queries into transactions.
- Additional optimization here was removing the `getAllPosts` method from CollectionService. This is an attempt to reduce the API surface of the of the service before calling it a GA.
refs https://github.com/TryGhost/Arch/issues/16
- Having transactional collection post updates makes sure there are no race conditions when updating collection_posts relations. Without the transactions collection was prone to update relations based on a stale state causing problems like described in the linked issue
refs https://github.com/TryGhost/Arch/issues/16
- The generic "UpdateAllCollections" logic should not be used as the mapped Post's delete/add/edit events should be sufficient in maintaining collection's state
refs https://github.com/TryGhost/Arch/issues/41
- When an new collection is created the relational "tags" filter is now picked up properly and appropriate posts matching the tag filter are assigned and stored in the collection. Example collection filter that is now supported: `tags:['bacon']`
- Additionally cleaned up returned collection post DTOs, so we return as little data as possible and add only the fields that are needed
refs https://github.com/TryGhost/Arch/issues/25
- When run against different DB Engines the returned order of collections belonging to a post is not consistent (SQLite vs MySQL). Having a primitive ordering by slug allows to keep the order compatible
https://github.com/TryGhost/Arch/issues/25
- This naming matches how the collection will be visible in the cards and how it's marketed. Naming it "index" even for internal purposes will get confusing.
refs https://github.com/TryGhost/DevOps/issues/45
- this switches the monorepo over to using Nx instead of Lerna, because
we don't currently need the versioning+publishing capabilities
- this also adds an `nx.json`, which allows us to enable task caching
- also adds `build:ts` to the TS projects, which is cached for fast execution
- how these interact with the dev.js script will hopefully soon be
reworked to be a better experience
refs https://github.com/TryGhost/DevOps/issues/45
- this moves the bulk of the tsconfig file to the `ghost/` folder and
simply extends this file in each of the TS lib packages we currently
have
- this makes it a lot easier to make single changes to our TS config
closes https://github.com/TryGhost/Arch/issues/27
- We need a more convenient method of fetching posts belonging to a collection than by collection's "id". This change adds an alias to the existing endpoint `GET /collections/:id/posts/`. A non-valid ObjectID in the parameter is treated as a slug.
refs https://github.com/TryGhost/Arch/issues/25
- The built in index (soon -> "latest") collection does not require any filtering so that it could contain an index of all posts in the system. All other automatic collections should have a filter defined.
We couldn't decide on the best way to encode this in the database.
e.g. deletable: true? or type: internal? but type conflicts with the
storage of manual/automatic.
For now we can use this, and add something in future if we're finding problems
When we end up wiring this to the database, this generator will also ensure
uniqueness by appending/incrementing a number on the end of the slug. Long term
it would be good to offload this to a shared slug service, this could also
ensure that slugs are unique globally or between multiple tables, if desired
We require that slugs are unique as slugs can/are used for routing purposes and
act as an identifier for a resource. As this is a core business rule, we want
to encode it in the entity so that it can be unit tested, and be enforced
regardless of underlying persistence layer
