no issue
- the original maintainer has deleted the project and released an empty version
- we're pinned at 5.5.3 and will stick to that version until a fork/replacement is found or required
no issue
- the dependencies are released at different cadences and are not interlinked
- allows independent upgrades when one dependency with a slow release is buggy
refs c1ecb6a572
refs https://github.com/TryGhost/Admin/pull/1830
- using `renovate-config-validator` it appears Renovate doesn't support extends within packageRules or at least requires direct selectors rather than extended selectors
- copied package rules from `@tryghost:pkgCSS` across rather than using `extends`
refs https://github.com/TryGhost/Admin/pull/1830
- Renovate hasn't tried to update any packages since January when the postcss dependencies were pinned and Renovate config updated to try and disable css related package updates
- it's possible the `enabled: false` was affecting everything because the wrong extends was used in the package rule. Swapped from `groupCSS` to `pkgCSS` to better match the intention of disabling specific packages
no issue
- we want to disable automerging of TryGhost dependencies in order to
allow commits that contain emojis and context for the bump
- similar to 54a09842a6
in Ghost, this commit adds the new preset to disable automerging of @TryGhost dependencies
no issue
- due to various levels of sub-dependency support across our postcss dependencies we'd ended up with three different versions of postcss installed (6, 7, and 8)
- pinned our dependencies to versions that all use postcss@^7
- we can't upgrade to postcss@8 because we make heavy use of `color-mod` which is no longer in the CSS spec and so the dependency providing it has not been updated
- switched from `postcss-easy-import` to `postcss-import` to drop the postcss@6 sub dependency (we weren't using any of the features that postcss-easy-import added over postcss-import)
- initial tests show CSS compilation times to have roughly halved
- disabled renovate for css dependencies to reduce noise for updates we can't merge
no issue
- now that we no longer have the `ember-sticky-element` dependency we're free to upgrade `ember-in-viewport`
- remove package.json resolution so latest version gets installed
- remove ember-in-viewport from renovate ignore config
- update `<GhScrollTrigger>` to match latest `ember-in-viewport` usage and convert to a glimmer component
- ensure `scrollableArea` is always set so that the trigger doesn't stop working after the first trigger
no issue
- having so many addons grouped into a single PR is difficult to manage when not reviewing, updating and merging frequently. If a single addon requires deeper work or breaks our node support range than it blocks upgrades on all other addons which then compounds required effort over time
no issue
- according to https://github.com/renovatebot/config-help/issues/220#issuecomment-487118205 it's the _last_ matching group that takes effect when determining which `packageRules` group a dependency is put in
- adjusted the order so that explicit excludes are not required and the ember-basic-dropdown addons are correctly grouped
no issue
- grouped `ember-basic-dropdown` and related `ember-power-*` addons together
- they share a common base and are going through a major breaking change so it's easier to upgrade them together
no issue
- the `config:base` preset sets a maximum of 2 PRs per hour
- we have specific timings for Renovate in this repo so the max limit is more hindrance than help
no issue
- ignore `ember-exam` until it's compatible with latest stable of `ember-mocha`
- see https://github.com/ember-cli/ember-exam/issues/238
- moved `ember-exam`, `ember-mocha`, and `testem` into their own group so changes to test env don't cause addon upgrade PRs to fail
