-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ability to disable whitespace control: Handlebars.parseWithoutProcessing
#1584
Add ability to disable whitespace control: Handlebars.parseWithoutProcessing
#1584
Conversation
This will definitely address a pain point WRT recast and whitespace, that I myself have definitely encountered. Thanks for this. 🙏 |
I can see the need, but I don't think that a compile-option is the right way to go here. A compile-option would suggest that the use-case is compiling and executing a template with whitespace-control disabled. But all you want is to build a clean, unmodified AST, correct? I think a second "parse" function should be exposed for the purpose of building tools. Maybe there are other modifications that are useful for tooling, that could be built into the second function. Consequently, the test-cases should not be along the lines of "shouldCompileTo" but more like the tests in the "ast.js"-spec: Build an AST and compare it to the expected one. Does that make sense? |
The PR adds the option to
Sure, that seems totally fine to me as well. What do you think it should be called? Where should it go?
Sounds good, thank you for reviewing! |
@nknapp - I just pushed another commit that separates Is that along the lines of what you were thinking? Do you have a better idea on the name of the (currently named |
How about But "raw" is already taken for But we don't have a timeline. I can't make one with the small amount of work I can put into this every day. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have added a review (this makes the current state more visible in the PR overview).
Thanks for your time @nknapp! I've updated with your latest round of feedback:
|
OK, just pushed another couple of changes:
|
Thank you. I will have another glance but all in all the PR looks good to me now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One single change, then we are done...
When authoring tooling that parses Handlebars files and emits Handlebars files, you often want to preserve the **exact** formatting of the input. The changes in this commit add a new method to the `Handlebars` namespace: `parseWithoutProcessing`. Unlike, `Handlebars.parse` (which will mutate the parsed AST to apply whitespace control) this method will parse the template and return it directly (**without** processing :wink:). For example, parsing the following template: ```hbs {{#foo}} {{~bar~}} {{baz~}} {{/foo}} ``` Using `Handlebars.parse`, the AST returned would have truncated the following whitespace: * The whitespace prior to the `{{#foo}}` * The newline following `{{#foo}}` * The leading whitespace before `{{~bar~}}` * The whitespace between `{{~bar~}}` and `{{baz~}}` * The newline after `{{baz~}}` * The whitespace prior to the `{{/foo}}` When `Handlebars.parse` is used from `Handlebars.precompile` or `Handlebars.compile`, this whitespace stripping is **very** important (these behaviors are intentional, and generally lead to better rendered output). When the same template is parsed with `Handlebars.parseWithoutProcessing` none of those modifications to the AST are made. This enables "codemod tooling" (e.g. `prettier` and `ember-template-recast`) to preserve the **exact** initial formatting. Prior to these changes, those tools would have to _manually_ reconstruct the whitespace that is lost prior to emitting source.
1f1e071
to
b58a228
Compare
Handlebars.parseWithoutProcessing
Just pushed another round of updates:
@nknapp - Please let me know if there is anything else that needs some tweaks. 😸 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for your patience and persistence in this.
I haven't decided on the date of the next release yet. Is this urgent for you or can it wait another couple of weeks?
I would have done the squashing myself, but well OK. I noticed that unsquashed commits are much easier to review. |
There are some bugs that are a bit difficult to work around in the codemod tooling that I am maintaining (things like ember-template-lint/ember-template-recast#155) that this helps resolve (once updated in tldr; I think I can "polyfill" this new method in my codemod tooling, if I run into issues there though I will let you know... |
Gotcha. I also wanted to fix up the commit message a bit (the main commit message was still talking about the original option I proposed).
Yes, I whole heartedly agree. The GitHub UI makes reviewing the delta between commits super simple, but when folks continually squash / amend that workflow is broken. FWIW, I have had some luck with the new "mark file as viewed" functionality in the GitHub pull request UI (this works across squashes), but it's still not as nice as leaving it unsquashed. |
Before you start building workarounds... I would like wait for #1583 to be ginishrd. Then I could probably release 4.5 on the next weekend. It won't be more than a couple of weeks at most. Maybe you can use a github dependency until then. |
If you want this for ember, you probably need a backport to 3.x, don't you? |
I might be able to release this evening. Do you know if you need the feature in 4.x or 3.x? |
We are using v4 over in
Ya, definitely no worries on timing from me. Thank you again for all of your help getting this into a good state. |
Really? A while ago @wycats asked for my opinion on how to proceed with the parser. He said Ember was using an older version and he was thinking about how to converge the code-base again, because Handlebars has features that are not used by Ember and Ember has other features like components. But OK. It's a good to know that you are using the current version. |
I have release 4.5 now. It was just good to have all this wrapped up. (will take a break now). |
When authoring tooling that parses Handlebars files and emits Handlebars files, you often want to preserve the exact formatting of the input. The changes in this commit add a new method to the
Handlebars
namespace:parseWithoutProcessing
. Unlike,Handlebars.parse
(which will mutate the parsed AST to apply whitespace control) this method will parse the template and return it directly (without processing 😉).For example, parsing the following template (feel free to review the AST on ASTExplorer):
Using
Handlebars.parse
, the AST returned would have truncated the following whitespace:{{#foo}}
{{#foo}}
{{~bar~}}
{{~bar~}}
and{{baz~}}
{{baz~}}
{{/foo}}
When
Handlebars.parse
is used fromHandlebars.precompile
orHandlebars.compile
, this whitespace stripping is very important (these behaviors are intentional, and generally lead to better rendered output).When the same template is parsed with
Handlebars.parseWithoutProcessing
none of those modifications to the AST are made. This enables "codemod tooling" (e.g.prettier
andember-template-recast
) to preserve the exact initial formatting.Prior to these changes, those tools would have to manually reconstruct the whitespace that is lost prior to emitting source.