Previous iterations of this codemod did not take full advantage of jscodeshift's (undocumented AFAICT) results API.
Thus, a user might see:
All done.
Results:
0 errors
58 unmodified
0 skipped
0 ok
Time elapsed: 3.029seconds
when their codemods.log file had multiple entries like this:
2023-03-14T11:25:08.799Z [error] [addon/controllers/foo.js]:
FAILURE
Validation errors for class 'FooController':
[actions]: Transform not supported - [destroy]: action name matches one of the lifecycle hooks.
Rename and try again. See https://github.com/scalvert/ember-native-class-codemod/issues/34 for more details
This discrepancy can be pretty confusing for users.
I did some code-reading and found that jscodeshift checks the output of the transform function and sorts the transform attempt into its corresponding results category based on the following:
Result
How-to
Meaning
errors
throw
we attempted to transform but encountered an error
unmodified
return string (unchanged)
we attempted to transform but it was unnecessary
skipped
return undefined
we did not attempt to transform
ok
return string (changed)
we successfully transformed
While the changes to make this happen for this codemod were trivial, I found that neither codemod-cli nor jscodeshift's testing helpers expect the transform to throw, so I had to re-write the testing helpers and get a little creative to expect errors and error messages. Thus, this PR is mostly testing changes.
Additionally, due to the nature of throwing to give an errors result, I had to remove the partialTransforms functionality. This means that the codemod will fail for the file if any object within the file fails. This is standard for jscodeshift codemods apparently and was the standard for this codemod until very recently when I changed it thinking it would be helpful. It turns out not to be helpful.
Fixes #523
Previous iterations of this codemod did not take full advantage of jscodeshift's (undocumented AFAICT) results API.
Thus, a user might see:
when their codemods.log file had multiple entries like this:
This discrepancy can be pretty confusing for users.
I did some code-reading and found that jscodeshift checks the output of the transform function and sorts the transform attempt into its corresponding results category based on the following:
errorsthrowunmodifiedstring(unchanged)skippedundefinedokstring(changed)While the changes to make this happen for this codemod were trivial, I found that neither codemod-cli nor jscodeshift's testing helpers expect the transform to throw, so I had to re-write the testing helpers and get a little creative to expect errors and error messages. Thus, this PR is mostly testing changes.
Additionally, due to the nature of
throwing to give anerrorsresult, I had to remove thepartialTransformsfunctionality. This means that the codemod will fail for the file if any object within the file fails. This is standard for jscodeshift codemods apparently and was the standard for this codemod until very recently when I changed it thinking it would be helpful. It turns out not to be helpful.