Proposal: alternate syntax for the character / in file systems

[vincent-hoodoo]

The current syntax for conditional files and folders is functional, but generates a file system representation that is really hard to understand and maintain.

Example:

If I want a brick to generate an android.dart file only if the boolean parameter android is true, I'm supposed to name a file {{#android}}android.dart{{/android}}.
This has the effect of generating a directory named {{#android}}android.dart{{ that contains a file named android}}

View in the MacOS finder:

View in VSCode

This split in a directory and a file doesn't match at all how we think about a single file.

Proposal

If another syntax for conditional files and folders was introduced, that doesn't include the character /, we could view them as regular files, which would match the mental model about them being a file.

Dummy suggestions:

• Could we use the double ## symbol for closing tags? like {{#android}}android.dart{{##android}}
• Could we use another available symbol? like {{#android}}android.dart{{^android}}

Migration path

If this new syntax was introduced, it could be distributed in a first step alongside the current syntax, but the current syntax would trigger a warning with a recommendation to migrate to the new syntax. Then after a few versions, the old syntax would go away.

[felangel]

Hi @vincent-hoodoo 👋
Thanks for opening an issue!

I'm definitely open to a proposal for an alternative syntax for conditionals.

What are your thoughts on something like:

{{if android}}android.dart{{end}}

It would just be an alternative syntax to the existing:

{{#android}}android.dart{{/android}}

We could also support if not like:

{{if not android}}not_android.dart{{end}}

As an alternative syntax to:

{{^android}}not_android.dart{{/android}}

The reason why I'd prefer not to do something like ## or ^ is because those symbols are already used within mustache so it would be confusing imo as those symbols would be overloaded.

Let me know what you think and sorry for the inconvenience!

[vincent-hoodoo]

Thank you for the response @felangel !

{{if android}}android.dart{{end}}

looks great.

Just a few remarks:

• do you think there could be an issue on some operating systems with the required space after if ?
• what do you think about making the closing tag more explicit, like {{endif}} instead of {{end}}?

A few other remarks not directly linked to this but related:

• would you also support and and or operators?
• would you support nested conditions?
• would you support {{else}}?

[vkammerer]

I just went through the closed issues and saw a comment about the backslash being interpreted the same way as the forward slash: #440
I tried it and it works, yay! it's much nicer to work with single files in the filesystem than having to deal with a "folder + file" representation.

@felangel Is it a bug or is the backslash meant to be interpreted the same way as the forward slash?

[felangel]

I just went through the closed issues and saw a comment about the backslash being interpreted the same way as the forward slash: #440 I tried it and it works, yay! it's much nicer to work with single files in the filesystem than having to deal with a "folder + file" representation.

@felangel Is it a bug or is the backslash meant to be interpreted the same way as the forward slash?

This is working as intended because mason supports windows, macos, and linux so the paths get normalized internally.

[vkammerer]

This is great news! I noticed that it is represented as a single file at least:

• on MacOS
• on Github: see my test at https://github.com/vkammerer/backslash_in_filename_test/blob/main/backslashed%5Cfile.dart

Not sure how it's represented on Windows though...

Should this then be the recommended way of templating conditional files?
If yes, this could also be the way the example bricks are implemented, which would make them much more understandable when browsing them on GH. It would for example remove the intermediate directory one has to navigate to, like at https://github.com/felangel/mason/tree/master/bricks/plugin/__brick__/%7B%7B%23android%7D%7Dandroid%7B%7B

[alestiago]

@felangel is there something blocking us from introducing the alternative syntax for conditionals?

I liked your proposed solution introducing if and if not. I'm not sure if end will introduce ambiguity if new alternative syntaxes are introduced. Regardless, sounds like a good readable addition in comparison with \ which usually mess up the files system trees in many softwares.

[jbikeler]

Using the current mustache syntax, I have tried both forward slash and backslash in my file structure and it is consistently breaking the directories after the slash. It seems the backslash trick is working primarily on Mac, but I am on Windows and I'm using VSCode as my editor.

[stan-at-work]

@felangel could you fix this, this is a big issue and could be fixed easely.

thx

[felangel]

@felangel could you fix this, this is a big issue and could be fixed easely.

thx

What’s your proposed solution? I’m not sure we ever landed on an agreed upon solution.

[vincent-hoodoo]

I renamed the issue to better reflect that what we are discussing here are the problems that come from using the characters / and \ in file system representations. @felangel If you prefer that I revert the title to what it was before, let me know, but I think that "conditional statements" are only one case of the more general issue with these special characters.

Could we identify a character that would be substituted with a slash? That way, we could (almost) keep adhering to the moustache syntax

[stan-at-work]

@felangel could you fix this, this is a big issue and could be fixed easely.
thx

What’s your proposed solution? I’m not sure we ever landed on an agreed upon solution.

Just have a readable non IDE breaking convention

I would go for:

{{if-true: android}}android.dart{{end-if}}
{{if-false: android}}android.dart{{end-if}}

or

{{#android}}android.dart{{end}}
{{^android}}android.dart{{end}}