No error or warning when using incorrect migration type values (e.g. addColumns, unsafeExecuteSql)

[aharbavets]

Description:

When defining migration steps in schemaMigrations, using incorrect type values like "addColumns" or "unsafeExecuteSql" instead of the documented "add_columns" or "sql" leads to silent failure: • No error is thrown. • The migration is not applied. • onSetUpError is not triggered. • The console shows no indication of the mistake. • The "Migration successful" log is missing, but there’s no clue why. This makes the debugging process extremely difficult, especially since "addColumns" and "unsafeExecuteSql" look plausibly valid.

Expected Behavior:

The migration runner should:

1. Validate type values and throw an explicit error or warning if a step has an invalid type.
2. Optionally provide a debug log suggesting correct values ('add_columns', 'sql', etc.).

Steps to Reproduce:

1. Define a migration with incorrect step types:

{
  toVersion: 2,
  steps: [
    { type: 'addColumns', table: 'session', columns: [{ name: 'userId', type: 'string' }] },
    { type: 'unsafeExecuteSql', sql: 'DELETE FROM session' },
  ]
}

2. Run the app.
3. Notice: • No errors in the console • No schema change takes effect • No “[🍉] Migration successful” log • App functions normally post-start, giving the false impression that the migration was applied ⸻

Environment:

• WatermelonDB version: 0.27.1 • Platform: iOS / Android • Adapter: SQLite ⸻

Suggested Fix:

Add schema validation to the migration parser to detect unknown type values and either: • Throw a descriptive error, or • Emit a console warning listing all unrecognized types This would save significant debugging time and help developers adopt the correct DSL syntax.

[Blue-smoke007]

I'm excited to apply for the opportunity to address the migration validation issue in WatermelonDB. After reviewing the behavior, it's clear that the current implementation silently ignores invalid migration step types such as addColumns and unsafeExecuteSql, which closely resemble valid values like add_columns and sql. This can lead to confusion and wasted development time due to the absence of errors, warnings, or logging when the migration fails to apply.

With my experience in JavaScript, schema-driven systems, and debugging subtle integration issues in cross-platform environments like iOS and Android, I'm confident in my ability to improve this part of the system. My approach would involve implementing strict schema validation during the parsing of schema Migrations so that any unrecognized type values are caught immediately. I would ensure that descriptive error messages or at the very least meaningful console warnings are presented to the developer.