running codemod on rendering tests breaks on < character

[hmajoros]

I've been running the codemod on all of my project's rendering tests, ala anything that has

import { setupRenderingTest } from 'ember-qunit';

We've actually had pretty good success for the most part, but I have noticed a fun / interesting bug: If you test JS file contains the character < inside a string, or inside a comment block, the codemod seemingly attempts to parse this as HTML & blows up. A few examples we had were things like:

test('assert correct string for < 99 records', async function(assert) { ... }

/**
 * @Title: assert that <memberName> is generated correctly
 */

Our workaround has been to just delete the characters < and > from any string / comment, run codemod, then add the characters back. Would be great is the codemod could be configured to only run on the actual hbs blocks inside the test instead of the entire file.

[suchitadoshi1987]

👍

[pete-the-pete]

The codemod also fails if the < is in a comment: ex. /**

• @Title: Render a thing with less than 4
• @Steps:
• GIVEN a thing with 1 < stuff < 4 */

[ghost]

I'm not sure where the best place to fix this is, but I recreated in https://github.com/ember-template-lint/ember-template-recast/pull/208. I created an issue upstream with more detail: https://github.com/ember-template-lint/ember-template-recast/issues/207

[rwjblue]

This codemod should not be running on JavaScript files at all...

[hmajoros]

@rwjblue fwiw, it would be really nice to be able to run these on rendering tests instead of needing to migrate those manually to angle-brackets syntax.

The codemod actually works almost unexpectedly well in JS files containing templates, but with a few snags

[chriskrycho]

If we do want to support running on JS (which seems like a win for rendering tests), we probably need to just make this very slightly smarter and have it check on the context to guarantee that the string being parsed is one that's being passed as an arg to the hbs "function".