Support prettier-eslint, prettier, and eslint later than v9.0.2, v1.19.1, and v5.16.0.
#304
Comments
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Dec 4, 2020
Done with ``` yarn upgrade --latest $(tools/test deps | grep eslint) ``` which was easier than 01593b3. One thing we neglected to mention in 01593b3, which still applies here, is that the version of ESLint used by `prettier-eslint-cli` is still 5, and it's unclear when (or if) that'll change [1], which is unfortunate. [1] prettier/prettier-eslint-cli#304
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Dec 4, 2020
Done with ``` yarn upgrade --latest $(tools/test deps | grep eslint) ``` which was easier than 01593b3. One thing we neglected to mention in 01593b3, which still applies here, is that the version of ESLint used by `prettier-eslint-cli` is still 5, and it's unclear when (or if) that'll change [1], which is unfortunate. [1] prettier/prettier-eslint-cli#304 Fixes: zulip#4253
chrisbobbe
changed the title
prettier-eslint (currently v11).prettier-eslint, prettier, and eslint later than v9.0.2, v1.19.1, and v5.16.0.
gnprice
pushed a commit
to gnprice/zulip-mobile
that referenced
this issue
Dec 8, 2020
Done with ``` yarn upgrade --latest $(tools/test deps | grep eslint) ``` which was easier than 01593b3. One thing we neglected to mention in 01593b3, which still applies here, is that the version of ESLint used by `prettier-eslint-cli` is still 5, and it's unclear when (or if) that'll change [1], which is unfortunate. [1] prettier/prettier-eslint-cli#304 Fixes: zulip#4253
|
Really interested in this one, in an annoying place at the moment where my project is on eslint 7 / prettier 2 but my preferred editor (neovim lsp) is using prettier-eslint-cli which seems to have quite a few indentation differences. |
|
Stale issue |
|
Go away stale-bot, there's no sign this issue has been fixed. :) |
|
this would be great. this package is cluttering up my yarn.lock file with old dependencies. prettier 2.2.1, prettier-eslint 12.0.0, etc would be fantastic. |
|
(The issue hasn't been fixed.) |
|
This issue is not fixed. |
This was referenced Jun 5, 2021
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jul 8, 2021
Done to follow the template-app change in facebook/react-native@635ac1ba5, on the path to the RN v0.64 upgrade. The default behavior on our Prettier version, according to the doc [1], is already `arrowParens: 'avoid'`, but it changes to 'always' in Prettier v2.0.0. The RN commit sets it to 'always', explicitly, to smooth the transition to Prettier v2. Might as well do the same, although the path to us actually using Prettier v2 might be complicated; see prettier/prettier-eslint-cli#304. [1] https://prettier.io/docs/en/options.html#arrow-function-parentheses That commit reports that the default behavior before Prettier 2.0 is like setting `arrowParens: 'avoid'`. It's looking unlikely that we have an easy path to using Prettier 2.0 (see prettier/prettier-eslint-cli#304), but we might as well follow the RN template app.
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jul 8, 2021
Done to follow the template-app change in facebook/react-native@635ac1ba5, on the path to the RN v0.64 upgrade. The default behavior on our Prettier version, according to the doc [1], is already `arrowParens: 'avoid'`, but that default will change to 'always' in Prettier v2.0.0. The RN commit sets it to 'avoid', explicitly, to avoid a silent change of behavior when upgrading. Might as well do the same, although the path to us actually using Prettier v2 might be complicated; see prettier/prettier-eslint-cli#304. [1] https://prettier.io/docs/en/options.html#arrow-function-parentheses That commit reports that the default behavior before Prettier 2.0 is like setting `arrowParens: 'avoid'`. It's looking unlikely that we have an easy path to using Prettier 2.0 (see prettier/prettier-eslint-cli#304), but we might as well follow the RN template app.
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jul 8, 2021
Done to follow the template-app change in facebook/react-native@635ac1ba5, on the path to the RN v0.64 upgrade. The default behavior on our Prettier version, according to the doc [1], is already `arrowParens: 'avoid'`, but that default will change to 'always' in Prettier v2.0.0. The RN commit sets it to 'avoid', explicitly, to avoid a silent change of behavior when upgrading. Might as well do the same, although the path to us actually using Prettier v2 might be complicated; see prettier/prettier-eslint-cli#304. [1] https://prettier.io/docs/en/options.html#arrow-function-parentheses That commit reports that the default behavior before Prettier 2.0 is like setting `arrowParens: 'avoid'`. It's looking unlikely that we have an easy path to using Prettier 2.0 (see prettier/prettier-eslint-cli#304), but we might as well follow the RN template app.
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jul 8, 2021
Done to follow the template-app change in facebook/react-native@635ac1ba5, on the path to the RN v0.64 upgrade. The default behavior on our Prettier version, according to the doc [1], is already `arrowParens: 'avoid'`, but that default will change to 'always' in Prettier v2.0.0. The RN commit sets it to 'avoid', explicitly, to avoid a silent change of behavior when upgrading. Might as well do the same, although the path to us actually using Prettier v2 might be complicated; see prettier/prettier-eslint-cli#304. [1] https://prettier.io/docs/en/options.html#arrow-function-parentheses That commit reports that the default behavior before Prettier 2.0 is like setting `arrowParens: 'avoid'`. It's looking unlikely that we have an easy path to using Prettier 2.0 (see prettier/prettier-eslint-cli#304), but we might as well follow the RN template app.
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Aug 4, 2021
Done to follow the template-app change in facebook/react-native@635ac1ba5, on the path to the RN v0.64 upgrade. The default behavior on our Prettier version, according to the doc [1], is already `arrowParens: 'avoid'`, but that default will change to 'always' in Prettier v2.0.0. The RN commit sets it to 'avoid', explicitly, to avoid a silent change of behavior when upgrading. Might as well do the same, although the path to us actually using Prettier v2 might be complicated; see prettier/prettier-eslint-cli#304. [1] https://prettier.io/docs/en/options.html#arrow-function-parentheses
|
@prettier, would you please consider reopening this and #303, and removing "no-issue-activity"? 🙂 I think it wasn't intended that the stale-bot would close them; please see 5ebffc9 where the stale-bot was turned off. Thank you! This may be the most important issue in the project, and it would be great to get it back on the list. 🙏 |
|
@kylemh I think this issue should be reopened. |
|
Agreed! |
4 tasks
|
Closed by #431 |
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
May 26, 2022
TODO: find out what we actually want :) and finish commit message Following the eagerly awaited resolution of prettier/prettier-eslint-cli#304 - add some @babel/ deps for peer-dep requirements - resolutions line to get prettier/prettier-eslint#749 Fixes: zulip#4254
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jun 2, 2022
Following the eagerly awaited resolution of prettier/prettier-eslint-cli#304 . And adjust our ESLint config so that we can do this with no new ESLint errors or suppressions. After this, we'll un-ignore the rules under "New rules we want", one by one, which will mean fixing the code that doesn't yet follow each rule. Greg says, about the formatting changes: zulip#5393 (review) > The formatting changes from the Prettier upgrade look fine. Some > code gets nicer (like `foo.bar().baz()` going on one line), some > gets less nice (like a lot of stuff getting an extra level of > indentation). I'm not sure I like it better on net; but Prettier > is designed as a take-it-or-leave-it package, and I don't have a > better alternative nor want to be stuck on an old version. So > 🤷 The added @babel/* deps are to satisfy peer-dependency requirements. The resolutions line gets us prettier/prettier-eslint#749 and can be removed when prettier-eslint-cli bumps its prettier-eslint version.
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jun 2, 2022
Following the eagerly awaited resolution of prettier/prettier-eslint-cli#304 . And adjust our ESLint config so that we can do this with no new ESLint errors or suppressions. After this, we'll un-ignore the rules under "New rules we want", one by one, which will mean fixing the code that doesn't yet follow each rule. Greg says, about the formatting changes: zulip#5393 (review) > The formatting changes from the Prettier upgrade look fine. Some > code gets nicer (like `foo.bar().baz()` going on one line), some > gets less nice (like a lot of stuff getting an extra level of > indentation). I'm not sure I like it better on net; but Prettier > is designed as a take-it-or-leave-it package, and I don't have a > better alternative nor want to be stuck on an old version. So > 🤷 The added @babel/* deps are to satisfy peer-dependency requirements. The resolutions line gets us prettier/prettier-eslint#749 and can be removed when prettier-eslint-cli bumps its prettier-eslint version.
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jun 3, 2022
Following the eagerly awaited resolution of prettier/prettier-eslint-cli#304 . And adjust our ESLint config so that we can do this with no new ESLint errors or suppressions. After this, we'll un-ignore the rules under "New rules we want", one by one, which will mean fixing the code that doesn't yet follow each rule. Greg says, about the formatting changes: zulip#5393 (review) > The formatting changes from the Prettier upgrade look fine. Some > code gets nicer (like `foo.bar().baz()` going on one line), some > gets less nice (like a lot of stuff getting an extra level of > indentation). I'm not sure I like it better on net; but Prettier > is designed as a take-it-or-leave-it package, and I don't have a > better alternative nor want to be stuck on an old version. So > 🤷 The added @babel/* deps are to satisfy peer-dependency requirements. The resolutions line gets us prettier/prettier-eslint#749 and can be removed when prettier-eslint-cli bumps its prettier-eslint version.
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jun 8, 2022
Following the eagerly awaited resolution of prettier/prettier-eslint-cli#304 . And adjust our ESLint config so that we can do this with no new ESLint errors or suppressions. After this, we'll un-ignore the rules under "New rules we want", one by one, which will mean fixing the code that doesn't yet follow each rule. Greg says, about the formatting changes: zulip#5393 (review) > The formatting changes from the Prettier upgrade look fine. Some > code gets nicer (like `foo.bar().baz()` going on one line), some > gets less nice (like a lot of stuff getting an extra level of > indentation). I'm not sure I like it better on net; but Prettier > is designed as a take-it-or-leave-it package, and I don't have a > better alternative nor want to be stuck on an old version. So > 🤷 The added @babel/* deps are to satisfy peer-dependency requirements. The resolutions line gets us prettier/prettier-eslint#749 and can be removed when prettier-eslint-cli bumps its prettier-eslint version.
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jun 9, 2022
Following the eagerly awaited resolution of prettier/prettier-eslint-cli#304 . And adjust our ESLint config so that we can do this with no new ESLint errors or suppressions. After this, we'll un-ignore the rules under "New rules we want", one by one, which will mean fixing the code that doesn't yet follow each rule. Greg says, about the formatting changes: zulip#5393 (review) > The formatting changes from the Prettier upgrade look fine. Some > code gets nicer (like `foo.bar().baz()` going on one line), some > gets less nice (like a lot of stuff getting an extra level of > indentation). I'm not sure I like it better on net; but Prettier > is designed as a take-it-or-leave-it package, and I don't have a > better alternative nor want to be stuck on an old version. So > 🤷 The added @babel/* deps are to satisfy peer-dependency requirements. The resolutions line gets us prettier/prettier-eslint#749 and can be removed when prettier-eslint-cli bumps its prettier-eslint version.
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jun 9, 2022
Following the eagerly awaited resolution of prettier/prettier-eslint-cli#304 . And adjust our ESLint config so that we can do this with no new ESLint errors or suppressions. After this, we'll un-ignore the rules under "New rules we want", one by one, which will mean fixing the code that doesn't yet follow each rule. Greg says, about the formatting changes: zulip#5393 (review) > The formatting changes from the Prettier upgrade look fine. Some > code gets nicer (like `foo.bar().baz()` going on one line), some > gets less nice (like a lot of stuff getting an extra level of > indentation). I'm not sure I like it better on net; but Prettier > is designed as a take-it-or-leave-it package, and I don't have a > better alternative nor want to be stuck on an old version. So > 🤷 The added @babel/* deps are to satisfy peer-dependency requirements. The resolutions line gets us prettier/prettier-eslint#749 and can be removed when prettier-eslint-cli bumps its prettier-eslint version. And run $ tools/tsflower unpack $ tools/tsflower pack to update TsFlower's output for the new Prettier version and rebase the patches atop that. I see some churn in the patches where it looks like a Git version is printed at the bottom, and mine differs from Greg's, hmm.
gnprice
pushed a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Jun 9, 2022
Following the eagerly awaited resolution of prettier/prettier-eslint-cli#304 . And adjust our ESLint config so that we can do this with no new ESLint errors or suppressions. After this, we'll un-ignore the rules under "New rules we want", one by one, which will mean fixing the code that doesn't yet follow each rule. Greg says, about the formatting changes: zulip#5393 (review) > The formatting changes from the Prettier upgrade look fine. Some > code gets nicer (like `foo.bar().baz()` going on one line), some > gets less nice (like a lot of stuff getting an extra level of > indentation). I'm not sure I like it better on net; but Prettier > is designed as a take-it-or-leave-it package, and I don't have a > better alternative nor want to be stuck on an old version. So > 🤷 The added @babel/* deps are to satisfy peer-dependency requirements. The resolutions line gets us prettier/prettier-eslint#749 and can be removed when prettier-eslint-cli bumps its prettier-eslint version. And run $ tools/tsflower unpack $ tools/tsflower pack to update TsFlower's output for the new Prettier version and rebase the patches atop that. I see some churn in the patches where it looks like a Git version is printed at the bottom, and mine differs from Greg's, hmm.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
prettier-eslint-cliat its latest is pulling in and using versions ofprettier-eslint,eslint, andprettierthat are getting a bit old; in particular, ESLint 6 has been out for a while now, and it would be great to be able to use it (or even ESLint 7). Here are the latest of those packages that are currently supported atprettier-eslint-cliv5.0.1 (the current latest):prettier-eslintv9.0.2 (^9.0.0 is the rangeprettier-eslint-cliv5.0.1 depends on)prettierv1.19.1 (^1.7.0 is the rangeprettier-eslintv9.0.2 depends on)eslintv5.16.0 (^5.0.0 is the rangeprettier-eslint-cliv5.0.1 depends on and the rangeprettier-eslintv9.0.2 depends on)Supporting ESLint 6 is currently blocked by #303.
The text was updated successfully, but these errors were encountered: