[karup]

What does this PR do?

bun run migration fails on Windows: Bun.Glob returns backslash-separated paths, so file.split("/")[0] kept the whole path as the migration name. Split on both separators.

How did you verify your code works?

• bun run migration --check passes with the fix (the remaining failure on this checkout is a pre-existing autocrlf line-ending artifact of the generated files, present on the base commit and absent on Linux CI)
• Migration generation for a new table completed successfully on Windows with this fix

[github-actions]

This PR doesn't fully meet our contributing guidelines and PR template.

What needs to be fixed:

• PR description is missing required template sections. Please use the PR template.

Please edit this PR description to address the above within 72 hours, or it will be automatically closed.

If you believe this was flagged incorrectly, please let a maintainer know.

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[opencodejr]

Thanks for tracking this down, @karup! I think this duplicates #55126, which makes the same one-line change in generatedMigrations, splitting on either separator to fix the Windows bun run migration failure reported in #44401. It's still open, so if you'd like to help, testing it on Windows or leaving a review there would be very welcome.

[karup]

Superseded by #55126, which fixes #44401 with the same one-line change (generatedMigrations splitting on either separator). I verified that fix on Windows with Bun 1.3.14: with file.split(/[\\/]/)[0], both bun run migration --name ... and --check from packages/core work, and the generated migration/snapshot output is byte-identical to the forward-slash case. Closing in favor of #55126.