no issue
- micro-refactor that came out of a bigger draft-replies refactor, splitting out early to keep main change cleaner
- adjusted nested ternary style and naming to improve clarity
- added unit tests to ensure the logic behaviour stayed consistent
- cleaned up useless dummy unit test file
ref https://linear.app/tryghost/issue/DEV-32/remove-migratejs-script
- we want to switch to using this code path instead of our separate
migrate.js script on Pro
- the main things we're missing are metrics + monitoring for when things
go wrong, so this adds that to the DatabaseStateManager
- this allows us to eventually delete the script without losing
functionality
- the code kept an array of IDs, and would check new entries against the
values of this array
- this algorithm is O(n^2) and became quite slow when the site had a lot
of redirects
- we can do away with this entirely, and just compute the keys of the
redirects to get the IDs
- this speeds up loading redirects by 3x or so
- this will prevent the `ready` variable from being set to true if there
is an error with minification, as we have not correctly generated the
assets yet
- we don't need any of these fields to do URL service calculations, so
we can exclude them from being fetched, which improves performance of
URL service init
- ultimately, we should switch this to an include list to make this more
explicit
- this code is on the hotpath for the URL service and has shown to be
slow for sites with a lot of posts
- this is due to the overhead of the lodash functions we use here
- we can take advantage of how JS executes if-statements and move the
variable into the if-statement, which lazy evaluates it (for the URL
service, this branch is not hit, so it's a big win)
- this cuts about 2% from CPU time
- this code is a hotpath for the URL service and has shown to be slow
for sites with a lot of posts
- this is because of the overhead of lodash
- we can just do away with lodash and use native JS, which has
a negligible performance cost
- this cuts about 5% CPU time during boot of large sites
- moment calls are unbelievably heavy and we should do away with it
where possible
- this code doesn't need moment and we can just use native JS Date here
- this saves about 5% CPU time when booting sites with a lot of posts
- this code has shown to be chronically slow, due to the `Object.assign`
- we don't really need this, as we can just use a normal assign in this
case
- this cuts 15% CPU from boot time for sites with a lot of resources
(posts)
- it turns out we it the false case of this if-statement quite a lot,
and _generateUrl is heavy enough that we should try and do it less
- by moving it into the if-statement, we cut 4% CPU time from boot on
heavy sites
- lodash adds non-negligible runtime to this loop, so we can just
replace it with native JS and cut 3% CPU time from boot for sites
with a large number of posts
- we have to deserialize the values from the DB to turn them into moment + boolean values
- the use of lodash adds unnecessary overhead to the function, and writing it in native JS
is a low faster
- also fixes the naming of the functions to make it clearer in flamegraphs
no issue
- This removes the `casper` and `source` submodules from the VSCode
source control sidebar to simplify the view.
- It also points all of VSCode's `git` commands in the command palette
to the root repository (Ghost), so you don't have to specify which repo
you want to commit to every time.
- With this, you can simply run the "Git commit all" command in VSCode
(and optionally map a keybinding to it), which adds all changed files to
the commit and prompts for a commit message.
no issue
# Before
The pre-commit hook would abort the commit if any submodules were staged
for commit, and prompt the user to manually un-stage them and retry the
commit.
# Now
The pre-commit hook automatically un-stages any staged submodules, then
allows the commit to proceed.
# Why?
This was a daily annoyance that caused many common git commands to
abort, and required manual un-staging of the submodules before retrying
the commit:
- `git commit -a`
- `git add . && git commit`
- `git add -A && git commit`
If we ever _do_ need to commit submodules, we can always add them back
and run `git commit --no-verify` to accomplish that (which we would have
needed to do before regardless). This should accomplish the same goal of
not allowing submodules to be committed, but reduce the day to day
friction of making commits in Ghost.
no issue
- config helpers are required early during boot and it requiring lodash added some unnecessary require+compile time
- switched to using an inlined escapeRegExp function in place of requiring lodash
no issue
- config utils are required early during boot and it requiring lodash added some unnecessary require+compile time
- switched to using native JS for the few lodash methods we used
no issue
- bumped gscan version to provide `skipChecks` flag to `check` function
- added `optimization:themes:skipBootChecks` config flag defaulting to `false` to maintain current behaviour
- updated theme service initialization to use `skipChecks: true` when the config flag is set
- we only want to skip the checks during boot in specific cases to improve performance, they are still useful for general development and any production use-cases where themes get edited directly on the server
- updated our theme validate module to accept and pass through `skipChecks` option
- switched the `isZip` positional argument of `validate.check()` to an options object property to make usage cleaner
- right now, we minify the assets on boot. This is wasteful because they're not even needed
- this commit implements a change which lazy-minifies these assets and
allows for cache invalidation when the theme changes
- it also introduces some middleware that each asset calls to ensure
that the assets are minified before serving
no issue
- avoid accessing `mobiledocLib.mobiledocHtmlRenderer` directly to access the `render()` method in favor of using `mobiledocLib.render()` instead
- standardising on this pattern should help avoid accidentally requiring the full library before we have a need to render
no issue
- the lazy-loading `mobiledocHtmlRenderer` getter was being accessed by the email renderer that gets initialized during boot
- switched the pattern to match our lexical lib where we have a `render()` method that doesn't load the renderer until it's actually needed
- we don't need to require the entire package and this costs 5% of our
boot time
- this commit bumps NQL to the latest version, which fixes the requires
to help with treeshaking and loading less code
