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
refs https://github.com/TryGhost/Team/issues/3169
- With the new architecture all possible dependencies should be injected rather than required directly - this applies to the DomainEvents module as well.
refs https://github.com/TryGhost/Team/issues/3169
- This piece of logic handles the 'post.added' model event mapping to Collection's PostAddedEvent domain event and logic related to updating collections when the new post is added.
refs https://github.com/TryGhost/Team/issues/3169
- The collection entity properties used to be modified, which is not a good practice for logic encapsulation. Extracted editing logic to it's own method which can also contain validation logic when wrong data is passed when editing a collection.
refs https://github.com/TryGhost/Team/issues/3169
- When handling a single generic event the code becomes riddled with if statements to detect correct "data" that is being passed with the event. Switching to have a domain event per model event helps solving this problem and makes code more readable.
refs https://github.com/TryGhost/Team/issues/3169
- To make the coupling to Ghost's model events as loose as possible added a bridge that maps model events to domain events. These domain events it what the collections module can subscribe to to make necessary updates.
refs https://github.com/TryGhost/Team/issues/3428
- I'm taking an approach of adding specialized support for each event one-by-one.
- The post resource deletion event is the most straight forward and works same for both types of collections.
refs https://github.com/TryGhost/Team/issues/3423
- This is a convenience method that should allow fetching collections by their slug. It is a great developer experience for in case when fetching built-in collections like "featured" and "index", so can avoid an extra call to find the collection and it's ide one wants to use.
refs https://github.com/TryGhost/Team/issues/3423
- When querying for posts that belong to a collection we should be returning full post information just like we do for Posts API.
refs https://github.com/TryGhost/Team/issues/3376
fixes b4a97d084f
- The in-memory stores are not cleaned up when the Ghost instance is "shallow restarted" between test suite runs, causing the initialization of built-in collections to run multiple times. The initialization should ever add the collections once.
closes https://github.com/TryGhost/Team/issues/3170
- When resources that are related to automatic collection filter are updated the posts in collections should be updated as well.
- This change adds a super-basic way to track changes in post/tag/author resources and updated all automatic collections when any of those resources change. In the future we can optimize the update process to be more performant, but it's good enough for current needs
refs https://github.com/TryGhost/Team/issues/3170
- This implementation allows to create an automatic collection with a filter defining automatically populated posts that belong to a collection
- To populate collection using a filter the API client can send a `filter` property along with a collection request
- Filter values are compatible with the filters used in Content API (https://ghost.org/docs/content-api/#filter)
