Open alexrafael10 opened 3 years ago
Ah yes, didn't notice that.
Simply reading the endOfLine
option from prettier config is not a perfect solution.
For example, it will cause a false negative:
<scirit>\r\n
// ...\r\n
</script>\n
In this case, the last \n
will be replaced by \r\n
, and won't be reported by prettier.
So respect the original eol char could be a better solution 🤔
Yeah, i actually noticed that yesterday haha i came up with this:
const endingTag = `</${type}>${content.includes('\r\n') ? '\r\n' : '\n'}
My only worry for this is that to make it false it will need to parse the whole content in order to say "ok there is no \r\n
in this file. (had to come up with a very quick and dirty solution for my work)
This is how eslint guys achieve this> https://github.com/eslint/eslint/blob/master/lib/rules/linebreak-style.js
any plan to fix it?
in the
processSFCBLock
the code is doingThe usage of
\n
it's making repos not using LF show an unfixable error at the end of SFC</script>
tag:It will never go away since the plugin is parsing the
\n
added when parsing the SFC.I'm forking in order to not mess with my repo line ends.
If this is actually an issue and maybe no one wants to spend time on it I can take some time maybe to send a PR controlling which line break char is inserted reading from
endOfLine
prettier option.Cheers.
Ps: your plugin saved me so much pain introduced by prettier and vue lol