Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: split out task running and config loading #677

Open
wants to merge 353 commits into
base: main
Choose a base branch
from

Conversation

apaleslimghost
Copy link
Member

split from #630. allows running tasks from a previously-loaded config.

apaleslimghost and others added 30 commits April 9, 2024 17:44
and make schemas package exports more consistent
(and make the zod inference helper type generic)
Co-authored-by: Ivo Murrell <ivo.murrell@ft.com>
Co-authored-by: Ivo Murrell <ivo.murrell@ft.com>
…compatible

Slightly more backwards compatible
…ions

Backwards compatible .toolkitrc options field
…atible-well-sort-of

Even more backwards compatible (well sort of)
fix: remove check for undefined commands
chore: remove duplicate runInit call in runTasks
ivomurrell and others added 20 commits May 14, 2024 12:09
Manually bump updated prerelease packages
Fix Task options not being unwrapped when returned from Zod
Manually bump updated prerelease packages
Custom plugins can be imported using a relative path. We had previously
switched to resolve-pkg to be able to handle plugins without an
entrypoint, however this package can't handle resolving relative paths.
Additionally, resolve-from's functionality is now available in Node's
require API so let's remove both packages (this will also make it easier
to migrate to ESM in the future).

Now we can roll our own resolution logic that takes what we were using
from the resolve-pkg package (resolving a package.json instead of an
entrypoint) and adds adds support for relative paths too.
This allows custom plugins (who won't have a schema associated with
them) to still use task options.
Manually bump updated prerelease packages
This partially reverts d1374d1, which I think was a mistake as we
already remove the EOL character normally added by winston, and we skip
appending a newline character to messages if it has a `process`
attribute. So it meant that the only newlines that would be preserved
were ones that happened to not be at the end (or start) of a stream
flush.
Because we were declaring a regex within a template literal we needed to
escape the backslash in the `\s` whitespace meta group. I we don't, the
backslash is parsed as an escape character for the template literal, not
the regex, and is replaced with a literal `s` as `\s` is not a valid
escape sequence. This means the regex would search for an `s` instead of
whitespace. This doesn't affect the unescaped `\n` as the escaped `\n`
and the literal `0x0A` ASCII character are (roughly) equivalent in a
regex.

Instead of fixing the incorrect `\s`, let's remove it entirely and not
trim whitespace characters, just newlines, as I'm not sure we actually
want to strip indentation from hooked console logging.
Fix lack of newlines in subprocess logging
Manually bump updated prerelease packages
build: update and simplify create-plugin script
@apaleslimghost apaleslimghost requested a review from a team as a code owner July 25, 2024 16:03
Base automatically changed from task-context to main September 5, 2024 16:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants