-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
newline-after-import
breaks again
#441
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Seems to be I'm disqualifying |
I don't have any |
I'm not either. If it doesn't, it'd be ideal to have a failing test case. This was the first thing I could come up with just syntax-ing around that threw the same exception, and while I could imagine other execution states that could throw the same error, I was unable to imagine syntax (and consequently, test cases) to go with them. |
Published v1.11.0 to |
Sadly this still occurs. How can I help figure out which file is causing the issue? |
Bummer. 😞 Best idea I have had: some sort of |
What about modifying the rule in |
@benmosher OK, I think I found it: switch (foo) {
case '1':
return require('../path/to/file1.jst.hbs')(renderData, options);
case '2':
return require('../path/to/file2.jst.hbs')(renderData, options);
case '3':
return require('../path/to/file3.jst.hbs')(renderData, options);
case '4':
return require('../path/to/file4.jst.hbs')(renderData, options);
case '5':
return require('../path/to/file5.jst.hbs')(renderData, options);
case '6':
return require('../path/to/file6.jst.hbs')(renderData, options);
case '7':
return require('../path/to/file7.jst.hbs')(renderData, options);
case '8':
return require('../path/to/file8.jst.hbs')(renderData, options);
case '9':
return require('../path/to/file9.jst.hbs')(renderData, options);
case '10':
return require('../path/to/file10.jst.hbs')(renderData, options);
case '11':
return require('../path/to/file11.jst.hbs')(renderData, options);
case '12':
return something();
default:
return somethingElse();
} |
It appears that |
Makes sense. Same thing was happening with the arrows; the scope position comes back as -1 and thus the statement is undefined. Thanks for the repro, I'll debug and try to trace it back from there. May add a debug logger to get the file name as you've suggested, as well. |
Turns out the Will publish as 1.11.1, and then we can reopen if it's still broken (for this or new reasons). Did add logging as well, so |
Now that #386 is resolved, I'm now getting the following:
The text was updated successfully, but these errors were encountered: