Hi, I'm investigating whether I would be able to improve the Svelte plugin situation. So, eslint-plugin-svelte3
strips JSX and only returns JS (preprocess
returns an array with a single string), but prettier-plugin-svelte
expects a whole .svelte file and crashes. So we currently cannot use eslint-plugin-prettier
.
I'm assuming that the eslint plugin is wrong here, since Prettier has a Svelte plugin to parse whole files with, and eslint-plugin-react
, for example, passes the whole file (although I guess Svelte is closer to Vue than React).
Hoping that someone can confirm or clarify!
There's an interesting comment in eslint-plugin-prettier.js
on line 189, which says that if Prettier supports the same (non-JS) language as a processor, we want to process the source as JS instead of guessing the parser, which sounds like the opposite of my conclusion above, though. So I'm a bit lost.
prettier-plugin-svelte
console-logs some AST thing before it throws, and my vim plugin w0rp/ale
which is running Prettier, overwrites my code with this output. I can undo, but it's sort of scary. So I'm wondering, from the perspective of Prettier, is the fault with vim/ale, or should prettier-plugin-svelte
not print?
why is prettier formatting both the implementations differently —
type O1 = {
A: number
}
type O2 = {A: number}
type O1 = {
A: number;
};
type O2 = { A: number };
Hello. I'm new to prettier and I run to the problem with formatting my async / await functions. In eslint configuration I have this rule dissabled have rule space-before-function-paren but still prettier is formatting the code incorrectly.
Expected formating:
test('Refresh token', async() {
const response = await chakram.post(`/v2/sso/refresh`, {
refreshToken
})
Joi.assert(response.body, validators.responsePostRefresh)
})
Given:
test('Refresh token', async () {
const response = await chakram.post(`/v2/sso/refresh`, {
refreshToken
})
Joi.assert(response.body, validators.responsePostRefresh)
})
Can you help me to not have space between async and brackets. What Am I missing?
autocrlf
. Which is exactly what happened to me now.autocrlf
(unless this was changed recently too), so why oh why would you introduce conflicts with this only to protect from maybe 2% of Windows users who have their git settings wrong?