Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Migration stage #1180
Adds a migration stage to the compiler which is exposed through the taglib api via a new
This PR also moves over some of the existing transform based migrations (assign, var, invoke, and imperative rendering). It also adds a new migration for (and deprecates) inline control flow directives (<div if(x)>`).
This piggybacks off of #1179.
@@ Coverage Diff @@ ## master #1180 +/- ## ========================================== - Coverage 90.48% 90.48% -0.01% ========================================== Files 314 317 +3 Lines 11982 12042 +60 ========================================== + Hits 10842 10896 +54 - Misses 1140 1146 +6
Dec 3, 2018
5 checks passed
@ianvonholt it was something we have been talking about for a while, although I wish we were a bit more transparent about it.
Here is the reason:
We have seen this particular syntax is frequently used in ways that have caused confusion among developers. Specifically it's very easy to glance over where these (important) control flow statements are taking place. I think our example illustrates one of the reasons behind this, which is that it can simply be very tricky to keep on top of formatting this in a readable way especially when attributes start to pile up.
The value add for this feature was primarily around terseness and readability (which is not something we want to move away from) however I think In this case it ended up becoming more of a foot gun in the language. In examples (like the one you showed) it does look nice, but when there are other attributes on the tag (as is often the case in real-life, non-example code) readability actually suffers.
On top of this, these directives are yet another thing that new developers have to learn when on boarding to the language and also a feature that makes the framework a bit harder to maintain (two ways to do everything can complicate the code base).
Because of this, and because it is an extremely easy feature to automatically migrate, we've decided deprecate it here in Marko 4. It will be removed in Marko 5.
Our recent work has been focused on creating a migration layer in the Marko compiler so that most of these features you are seeing deprecation warnings for can be automatically migrated by marko migrate.
As @DylanPiercey mentioned, this is something we've been discussing for a while. It happened here because not doing so would have required some extra effort in implementing some of the things in this PR (and future migration related PRs).
One of the reasons we do deprecations in advance is so that users can see these warnings and take things up with us if we're missing a use case. So this isn't 100% set in stone, but I do think it's the right path forward.