Closed Nitrino closed 7 years ago
I'm not sure if we should do this with js-like syntax, after all the comment syntax in .haml and .slim uses only one /
and block comments are completely different from js-like block comments. Wouldn't it be better to create a new set of regex patterns for languages like these two?
It will be better to use a new set of pattern, but it will increase a lot the complexity to create new functionality.
I was already thinking of at least partially rewrite the way the regex patterns are built because there is a lot of duplication going on and I'm reaching a point where the patterns become unmaintainable. I was also thinking of using the xregexp lib to better document what all of the patterns are actually doing.
All in all I'm not very eager of forcing js comment syntax on unrelated language syntax even if it is similar. I'd like to ask @jsoverson what he thinks of it but he seems to not have spare time to work on this project.
Instead of including such hacks to code, maybe a configuration option for file extension maps would be better? This case could be solved by specifying something like {"haml": "js", "slim": "js"}
, and it won't cause any dilemma of doing a breaking change in the future by supporting a language natively.
@Nitrino, I've implemented passing the type of file to be processed as an option. Could you please verify whether that is a viable option for you to use preprocess
with this option to process haml
/slim
files?
This pull request adds the
.haml
haml and.slim
slim files extensions to those that are supported by the js regex.