3.5.0.1871: trailing-newline regression + three apply-patch/validate inconsistencies (TZ fix verified)

[upsite4k]

Summary

Followups from testing 3.5.0.1871 against a Laravel project (90 entities, 115 pre-existing migrations). The TZ-recompute fix from this release works as advertised. One trailing-newline issue still reproduces, plus three inconsistencies between -cli-apply-patch and -cli-validate worth fixing together.

1. UTC datetime fix — verified

<migrations timezone="…"> auto-populates on the first -cli-apply-patch (no GUI step required for headless use). With the exporting host's TZ matched to the original generator's, all 115 migration UTC comments are now byte-stable across servers.

2. Trailing newline on every exported migration — still reproduces on 1871

With #1 working, this is now the sole remaining byte difference between historical migration files and freshly-exported ones: a single appended LF.

on-disk  last 8 bytes :  \n  }  \n  }  \n
exported last 8 bytes :      }  \n  }  \n  \n

od -c of the trailing bytes from the same file before and after -cli-export:

on-disk  : } \n } \n
exported : } \n } \n \n

48,531 bytes on disk → 48,532 bytes after re-export. Reproduces on 115/115 migration files in this project. Happy to attach two files plus the .skipper project to a private channel if helpful.

3. add_index silently drops fields when passed a string instead of an array

// Both accepted with status:"ok" and ops_executed incremented;
// only the string form silently drops the field reference.
{"op":"add_index","args":{"entity":"Beruf","name":"kurz","fields":"beruf_kurz"}}     // → <index name="kurz" uuid="…"/> with no <index-field> children
{"op":"add_index","args":{"entity":"Beruf","name":"kurz","fields":["beruf_kurz"]}}   // → correct: <index-field name="beruf_kurz" …/>

The empty index produced by the string form exports as $table->index([], 'kurz'), which Laravel rejects at migrate time. Either accept the string as a single-element array, or reject with INVALID_OP — silent drop is the worst outcome.

4. -cli-validate doesn't flag <index> elements with zero <index-field> children

Closely related to #3, but independently fixable. An index with no field children passes validate (error_count: 0) and then breaks the export's migration. Suggest an INDEX_NO_COLUMNS (or similar) check.

5. add_field / update_field silently drop unsigned: true

{"op":"add_field","args":{"entity":"Beruf2","name":"ref_id","type":"bigInteger","unsigned":true}}

Result XML:

<field name="ref_id" type="bigInteger" required="true" uuid="…"/>

No unsigned="true" attribute on the resulting field. The framework-template PK created by add_entity does carry unsigned="true", so the data model supports the attribute — it's the user-facing op that doesn't honor the arg.

6. -cli-apply-patch and -cli-validate disagree on the type vocabulary

{"op":"add_field","args":{"entity":"Beruf3","name":"ref_id","type":"unsignedBigInteger"}}

apply-patch accepts the op verbatim:

<field name="ref_id" type="unsignedBigInteger" required="true" uuid="…"/>

-cli-validate on the resulting XML returns error_count: 1:

INVALID_FIELD_TYPE: Invalid field data type 'unsignedBigInteger' (object: \App\Models\Beruf3.ref_id)

Either apply-patch should reject unknown type strings, or both verbs should agree on what's valid.

Combined effect of #5 and #6: there's currently no -cli-apply-patch path to produce an unsigned non-PK bigInteger column. Workaround is to omit the column from the .skipper and add it via a hand-written follow-up Laravel migration outside the Skipper-generated set.

Environment

• Build: 3.5.0.1871 Linux
• Invocation: headless (QT_QPA_PLATFORM=offscreen, stdin closed)
• Project: Laravel template, full license, project's <migrations> element now carries timezone="Europe/Berlin" (matches the historical generators)

[ludekvodicka]

Thanks. Next time, please create one ticket per issue, i think it will be better for discussion/marking as complete.

[ludekvodicka]

regarding #2, this is strange. can you please create some minimal test case where is this reproducable?

[ludekvodicka]

regardnig #2, report from our test agent:

#2 — Trailing newline in exported files

We tried to reproduce this but couldn't. Here's what we tested:

1. Created a fresh Laravel project via CLI (-cli-create-project), added entities (User, Post) with fields, associations, and indexes via -cli-apply-patch, then exported with -cli-export
2. Exported an existing test project (Test001-entity from our Laravel migration test suite) that already has migration revisions
3. Inspected raw bytes at the end of every exported file — both migration PHP files and model PHP files

Result: All exported files end with exactly }\n (closing brace + single newline, hex 7D 0A). No extra trailing newline or blank line was found. This matches our reference test files that have been stable for years.

Could you share a specific .skipper project file where you see the extra trailing newline after export? That would help us reproduce and fix it.

[ludekvodicka]

#1 — UTC timezone fix ✅ Fixed
Verified working. Note: to use this fix, you need to open the project in the new Skipper version, save it (which writes the new timezone flag into the project file), and then export. The timezone is stored per-project so UTC conversion uses the correct offset.

#2 — Trailing newline regression ❓ Cannot reproduce
We exported multiple Laravel projects (fresh and existing with 115+ migrations) and inspected raw bytes at the end of every file. All end with }\n — exactly one newline, no extra blank line. The reference test files match this pattern.

Could you share a .skipper project file where you see the extra trailing newline? That would help us reproduce and fix it.

#3 — String field parameter silently dropped in add_index ✅ Fixed
add_index now accepts fields as both a string ("email") and an array (["email", "name"]). Previously a string value was silently ignored.

#4 — Index validation gap ✅ Fixed
-cli-validate now reports an INDEX_NO_FIELDS warning for indexes that have no field columns defined.

#5 — Unsigned attribute ignored ✅ Fixed
add_field and update_field now correctly handle the unsigned parameter.

#6 — Type vocabulary mismatch ✅ Fixed
add_field and update_field now validate the field data type against the project's ORM configuration. Invalid types (like unsignedBigInteger in frameworks that don't support it) return an error immediately instead of being silently accepted.

All fixes include integration tests. Available in lastest build here https://www.skipper18.com/support/402/downloads-skipper-beta