feat(emigrate): the journey to v2 (WIP) #246
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Instead of having different kinds of plugins there's now a plugin inspired by Astro's integrations that's based on hooks. Each plugin can decide which hooks to implement and depending on what the plugin decides to do in each hook its role varies. For each migration command a context is built and when it's run it's going through different phases, where the first phase is loading config and plugins, which themselves can modify the config (to for instance automatically add additional plugins). The next phase is for collecting and loading migrations where each plugin can register migrations to run (the collect step) and how to do it (the load step). Thanks to this it's now possible for plugins to run their own migrations as part of the migration, for instance if a plugin needs/wants to change the data model for its history table. With this Emigrate is no longer relying on migrations being files either, a migration can be as simple as an ordinary function. To ease registering functions as migrations (and to for instance run Emigrate without a CLI) there's now a built-in "inline" plugin that can do that. With this the "directory" option is no longer required and to get the old behaviour the built-in "directory" plugin should be used instead. As plugins can both read and modify the configuration I might change the config interface so that the "directory" plugin is automatically loaded and used if a "directory" field is set in the config, so it's similar to the old behaviour. In this change no existing plugins have been changed yet though and the whole feature is a work in progress. So there's no actual breaking change just yet, as this is built in parallel with the existing functionality.
|
Member
Author
|
@copilot implement a "new-remove" command in a similar fashion to the "new-up" command in this PR and with corresponding tests using the same writing style as in this PR. |
18 tasks
|
@joakimbeng I've opened a new pull request, #247, to work on those changes. Once the pull request is ready, I'll request review from you. |
joakimbeng
changed the title
And limit concurrency...
* feat(plugins): implement new-remove command Co-authored-by: joakimbeng <1427383+joakimbeng@users.noreply.github.com> * fix: add eslint disable for no-await-in-loop and change migration filtering logic Co-authored-by: joakimbeng <1427383+joakimbeng@users.noreply.github.com> * test: add test for pre-aborted abortSignal in remove command Co-authored-by: joakimbeng <1427383+joakimbeng@users.noreply.github.com> * fix: use for...of instead of forEach in assertStorageRemoved Co-authored-by: joakimbeng <1427383+joakimbeng@users.noreply.github.com> * refactor: simplify remove command by removing lock and inline removal Co-authored-by: joakimbeng <1427383+joakimbeng@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: joakimbeng <1427383+joakimbeng@users.noreply.github.com>
Member
Author
|
@copilot implement a "new-list" command in similar fashion to the "new-up" and "new-remove" commands in this PR. Add corresponding tests written in the same style as the tests for those commands. |
3 tasks
|
@joakimbeng I've opened a new pull request, #248, to work on those changes. Once the pull request is ready, I'll request review from you. |
Implements the `new-list` command following the v2 plugin architecture pattern established by `new-up` and `new-remove`. ## Changes - **`packages/cli/src/commands/new-list.ts`** - List command that iterates migrations calling `context.finish()` for each. No locking or logging occurs. - **`packages/cli/src/commands/new-list.test.ts`** - Tests covering: - No migration execution - No storage locking/unlocking/logging/waiting - Command results for various states - Plugin callbacks with correct migration states - **`packages/cli/src/tests/plugin.ts`** - Added `'pending'` to `MockedFinished` type for list command compatibility ## Review feedback addressed - [x] Use `.mockImplementation` instead of `originalDoneHook` variable - [x] Add test for `assertCommandFailed` when there's a failed migration - [x] Destructure `cwd` option and pass to `createEmigrateContext` ## Notes Returns `false` when failed migrations exist in history—`finish()` propagates the error state by design. <!-- START COPILOT CODING AGENT TIPS --> --- ✨ Let Copilot coding agent [set things up for you](https://github.com/aboviq/emigrate/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot) — coding agent works faster and does higher quality work when set up for your repo. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: joakimbeng <1427383+joakimbeng@users.noreply.github.com>
This was
linked to
issues
Dec 3, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Emigrate v2
-y/--yes) that's required in non-interactive mode-y/--yes) that's required in non-interactive modenpm init @emigrateornpx @emigrate/create@emigrate/clito its own package (keep the name) and rename the leftover package to@emigrate/emigrateA new plugin system
Instead of having different kinds of plugins there's now a plugin inspired by Astro's integrations that's based on hooks.
Each plugin can decide which hooks to implement and depending on what the plugin decides to do in each hook its role varies.
Thanks to the hooks system it's possible for plugins, or directly in the Emigrate config, to handle graceful shutdowns like discussed in #169
Complete rewrite of migration logic
For each migration command a context is built and when it's run it's going through different phases,
where the first phase is loading config and plugins, which themselves can modify the config (to for instance automatically add additional plugins).
The next phase is for collecting and loading migrations where each plugin can register migrations to run (the collect step) and how to run them (the load step).
Thanks to this it's now possible for plugins to run their own migrations as part of the migration,
for instance if a plugin needs/wants to change the data model for its history table.
With this change Emigrate is no longer relying on/requiring migrations being files either,
a migration can be as simple as an ordinary function.
To ease registering functions as migrations (and to for instance run Emigrate without a CLI) there's now a built-in "inline" plugin that can do that.
This also means that the "directory" option is no longer required and to get the old behaviour the built-in "directory" plugin should be used instead. But as plugins can both read and modify the configuration I might change the config interface so that the "directory" plugin is automatically loaded and used if a "directory" field is set in the config, so it's similar to the old behaviour.
There will be breaking changes
In this change no existing plugins have been changed yet though and the whole feature is a work in progress.
So there's no actual breaking change just yet, as this is built in parallel with the existing functionality, but when it's finished this will be breaking changes everywhere.