Optional request rules syntax for migrations

[phillip-elm]

Request rules are typically quite clean and easy to read. I wonder if migrations could benefit from similar syntax?

Something like:

Schema::create('posts', [
  'id'         => 'big-increments',
  'user_id'    => 'big-integer|unsigned|foreign:users,id',
  'retweet_id' => 'big-integer|unsigned|foreign:posts,id|update:cascade|delete:restrict',
  'body'       => 'string',
  '@timestamps',
  '@soft-deletes'
]);

This could open the door for other useful macros, etc:

Schema::macro('uint64', 'big-integer|unsigned');

This idea would need some refinement for handling edge-cases before seeing the light of day - but the syntax has proven itself useful for request rules.

[mfn]

I know it's an after thought in the current migrations but at least you get some level of autocomplete via IDE even though it might not reflect it correctly in all cases.

That would be impossible with that syntax.

Also there are things like ->comment() for a column which IMHO would be awkward to have to squeeze into something like this syntax (it may be full human sentences, including | or :, which may be hard to parse otherwise).

👎 on this idea

[phillip-elm]

Normally I'd agree with any point for IDE auto-completion - but after extended use of the framework and a number of conversations within the Laravel community, I've observed that:

• The community seems to favour readability / "eloquence" over IDE autocompletion
• As you yourself mentioned, migrations don't seem to autocomplete very well as it is - typically for me in PHPStorm, after a few chained calls it stops working.
• We've all learned the syntax for request rules pretty well without the need for autocomplete, and the complete list is readily available when we need to look things up.
• For the most basic of migrations, I'm not sure IDE completion offers us anything over clean and readable syntax.

I also want to add that this idea is for optional, short-hand syntax on simple migrations - I'm not suggesting any sort of breaking change that would prevent using the current API when required.

When I opened an issue in the past favouring better IDE support for a commonly used method, Sir Otwell himself stated: "[...] attempting to constantly satisfy IDEs in a dynamic language like PHP feels like a bit of a lost cause [...]"

---

tl;dr: I'm not sure that the current state of autocomplete warrants dismissal of shorthand syntax that has been adopted (with success) elsewhere in the framework.

I'm not married to this idea myself - but I think it has potential. The rules syntax as it is exists to convert ugly validation boilerplate into declarative, easy to read statements. Sounds applicable to migrations.

[mfn]

I'm not suggesting any sort of breaking change that would prevent using the current API when required.

Yeah, but that means maintaining two things essentially doing the same. And one already exists.

I just don't see investing into something like this bringing anything on the table which would warrant the resources and then maintaining it 🤷‍♀️ I mean so far I could not identify actual benefits (but I feel totally open for this).

Rather, the outcome would having two ways doing the same thing and then sparking confusion in future teams which one to use, etc.

"[...] attempting to constantly satisfy IDEs in a dynamic language like PHP feels like a bit of a lost cause [...]"

And yet you will find A LOT of PRs only dealing with improving this.

Also, the "community argument" is like statistics you didn't fake yourself: I can link to #1409 and counter argue the community wants to go into a different direction.

[taylorotwell]

No plans to take any action on this at the moment.