"unquoted strings can contain +" reverted in 3.0.18?

[spaze]

Hi, the 3.0.17 version notes included "unquoted strings can contain +" and the now released 3.0.18 also includes the same note but I don't see it anymore in the code:

latte/src/Latte/Compiler/TagLexer.php

Line 123 in fca0a3e

(?<Php_Identifier> (?&label)((--?|\.)[a-zA-Z0-9_\x80-\xff]+)* )|

The commit 5b1d834 is now marked as not belonging to any branch.

Was this "unquoted strings can contain +" feature reverted in 3.0.18? Or postponed to for example 4.0 version? If it was reverted, can you please update the 3.0.18 release notes? :-) I've been using the "+" character in one of my libs so I'd like to know what's the situation so I can update the lib appropriately. Thanks!

[dg]

Someone reported an incompatibility, so I quickly reverted it, but it seems you not only noticed that commit but also started using it :-) I'll try to find a solution.

[spaze]

I see, thanks for the info!

I have been using the + sign before 3.0.17 for a "concat" feature in one of my libs ({customThing foo+bar} has echoed foo and bar resources together), then 3.0.17 has been released, and the feature stopped working. Happens, and I didn't have tests in my lib (which also happens and has been fixed now, hehe). I have changed it to {customThing foo + bar} - notice the spaces around the + char and was happy with it and now I also have tests 😊

Long story short, I don't need to use the "new" "unquoted strings can contain +" feature, I can just remove the "if latte > 3.0.17" from my tests and I'll be happy. I just wanted to understand the situation, which I do now. Thanks!

[dg]

So, you are actually the person who encountered the incompatibility caused by that commit. I was thinking that no reasonable person would concatenate two strings :-)

… why are you concatenating two strings? Why not just write foobar directly?

[spaze]

You're totally correct: I may not be the reasonable person I once used to be 😅 I've encountered the problem but since it's a small lib and because see the previous sentence, I've decided to accommodate to the change.

This will be a bit longer, sorry:

The foo and bar in {customThing foo + bar} are actually resource ids like in here
and then I have a custom tag {script} (and more in this Latte extension) that's used like {script foo} or {script foo+bar} (e.g. here), which takes the resource, or resources, "compiles" (during run time though) a final file by concatenating the contents of foo and bar files as per the config, and outputs <script src=compiledfile> to the template. I can also use the tag like {script foo+'look a string'+bar} and then the result would be a concatenation of the contents of the file with id foo, the string look a string, and the contents of the file with id bar. I use it for example here.

The lib is now 8 years old, it is unfinished also feature-wise, and sort of "emulates" some JS/CSS compilers. I don't use them mostly because they'd overcomplicate things for me in this case (a personal site). However, I like to overcomplicate other things, so one of the main features of the lib is that it can calculate SRI hashes of the compiled files (the integrity attribute) which makes zero sense when the files are hosted on the same machine. But you can't overcomplicate everything and have to choose 😅

Today, I'd maybe go with a full featured build process that would probably do the same thing as what the lib does, and thanks to HTTP/2 I wouldn't bother with multiple/more <script src=...> files but here we are. Right now, it is cheaper for me to update the lib (which also helps me to explore the Nette libs in more details when trying to understand why and how should I handle this) than to introduce or use a mature build system. I may introduce it one day though but so far I like to write PHP than to explore the JS/CSS ecosystem 😇

And that's why, when encountering the issue, I haven't bothered to file an issue, because I think the usage and the lib is non-standard and possibly not reasonable so I try to accomodate the upstream changes, which are, most probably, more reasonable.

Btw, this chat here is not complaining, I just wanted to be sure I understand the situation, I don't like to assume :-)

(Ok, I may just straight use this as the extension documentation because it's more detailed than the extension's own documentation which is quite easy as there's none 😆)

[spaze]

Or, I could change the syntax of the config file, support arrays in the configuration like

files:
  multiple:
    - foo.js
    - bar.js

and then use {script multiple} instead of {script foo+bar} but that would be a bit more work but if that would be what's needed...

See, I'd do anything, anything, to avoid a JS/CSS build system 😆

[dg]

Sure, I understand, you just process tokens in your own way, great. Anyway, let's pretend the commit "unquoted strings can contain +" never existed, and I promise I will never add it.

[spaze]

That's good news, thank you! I now have tests so if "never" comes one day, I'm ready 💪😆

Can you please remove the "unquoted strings can contain +" mention from the release notes? https://github.com/nette/latte/releases/tag/v3.0.18