-
-
Notifications
You must be signed in to change notification settings - Fork 191
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
ENOTDIR with virtual filenames from processors #393
Comments
I have the same situation when implementing linting code blocks for |
Personally I add a hack check for it in |
For anyone maybe interested, #401 should fix this issue, I just published Once that PR been merged and released, I'll deprecate it. |
Thank you, this solves the problem! Hope this PR will get merged. |
* feat: support processor virtual filename close #393 * refactor: normalize filepath first in case recursive virtual filename
What version of
eslint
are you using? 7.21.0What version of
prettier
are you using? 2.2.1What version of
eslint-plugin-prettier
are you using? 3.3.1Please paste any applicable config files that you're using (e.g.
.prettierrc
or.eslintrc
files)No
.prettierrc
.What source code are you linting?
What did you expect to happen?
npm test
should run without throwing an exception.What actually happened?
Credit to eslint/markdown#174 for originally reporting this. My examples are based on that issue.
eslint-plugin-markdown
v2 switched to use the new processor API that was released as part of ESLint v6. Instead of returning each extracted code block as a string, processors can now return both the source codetext
and afilename
. In the example code above, the code block's returnedfilename
would be0.js
, with the extension coming from the code block's syntax tag.The new processor API uses the code block's
filename
to construct a virtual filename asparentFilename + path.sep + index + filenameFromPreprocess
. In the example above, the code block's virtual filename becomesREADME.md/0_0.js
.Based on the stack trace and a bit of stepping in a debugger, it looks like the exception is thrown when the rule tries to load the
.prettierrc
for the file. If I setusePrettierrc: false
, a very similar exception is thrown in a call a few lines later.This exception would occur with any processor that uses the new processor API and yields virtual filenames.
Depending on what it might take to handle code blocks with virtual filenames, eslint/eslint#11989 may be a related issue.
The text was updated successfully, but these errors were encountered: