- added getSubdir, getSiteUrl and getAdminUrl methods from url-utils
- refactored them so they are designed to be bound by nconf
- exposed a bindAll method
- moved over the tests and refactor from a class instance to nconf bindings
no issue
Replaces the usage of ghost-ignition with @tryghost/ignition-errors,
and switched to using the more modern ES6 class syntax over the
`.call(this, ...)` syntax used previously in both Ignition and here.
- fixed type warnings
- introduced explicit use of bluebird to help with type warnings and also make it clear when we're actually using Bluebird features
- removed the class pattern in the simplest possible way
- have package-json expose only the public methods
- move parse to an independent, not public file so that we can test it independently still
- We are going to get rid of the internal i18n tool because it doesn't solve a real use case
- Instead, we have a new tpl utility that does basic string interpolation
- This makes this module less complex as it no longer requires dependency injection to work
- ts complains the value may be undefined but in reality it never is
- plus we don't care about this error in this context as the test is checking that the value is set to its default
- This mini helper wraps lodash template and supports `{...}` as the delimiters
- It's designed to use and support the exact same patterns we already have in our en.json strings
E.g. The {flagName} flag must be enabled in labs if you wish to use the \\{\\{{helperName}\\}\\} helper.
- This allows us to get rid of our old, broken i18n helper and still keep some of the smart messaging we have setup
- It also keeps the refactor surface area minimal
https://github.com/TryGhost/Team/issues/663
- When there is no parameter passed at all it was a generic 'Cannot read property 'value' of undefined' message which wasn't helpful in recognizing what the actual problem was
- Have added additional guarding logic to throw a descriptive error
no issue
- I've discovered the "IncorrectUsageError" error was silently swallowed and the method returned a false positibe when an allowlist limit type was called with incorrect parameters
- In cases like this it's best to surface the real error early otherwise the logic might produce unsafe results!
refs https://github.com/TryGhost/Team/issues/662
- There is a need to check if any of the current limits are over limit in Daisy. This method is the simplest possible implementation to check if any of them are over limit
- Possible future iterations might include a list of names of the limits that have been acceded and their error messages
- The `checkIfAnyOverLimit` method should be treated as a starter to work up the complexity as needed
