Compatibility with Prettier 3.0

[IanVS]

We're going to need to explore what it takes to be compatible with the 3.0 version of prettier, now in alpha: https://github.com/prettier/prettier/releases/tag/3.0.0-alpha.0

I haven't actually tried it yet, but I'm guessing we'll be broken, since upstream apparently does not work: trivago/prettier-plugin-sort-imports#171

[fbartho]

@IanVS — that’s a real bummer! We also want to work on the breaking changes we were proposing for the config. It sounds like once we have a sense of what we need to do for this 3.0.0 upgrade we’ll know a lot more about the feasibility of our changes.

[fbartho]

Ah! This is probably at least the first breadcrumb to look into: https://github.com/prettier/prettier/blob/1a602b590ec9ed5db01780939659c427e3d277b8/changelog_unreleased/api/12748.md

[IanVS]

I'd love to get #20 merged in, and then start working on breaking changes.

[IanVS]

I think I've tracked down why this has started to fail, and it's due to a change in the way that parsers are resolved: https://github.com/prettier/prettier/pull/13268/files#diff-c8358202bc5a3fdb28f467ec76840e377dd714156543353736f19a76c8c1a930

Previously, the last plugin defining a parser with a given name would "win", and since custom plugins are added to the end of the array of plugins, that meant our versions of the babel, flow, or typescript parsers would take precedence over the built-in ones. Now, a for .. of loop with an early return is used, so the built-in parsers are used instead.

I'll open an issue in prettier to see if they can suggest a way around this, but unless that happens, I think our only choice is to define our own parser(s), which means we would lose out on prettier automatically inferring the correct parser to use. :(

[IanVS]

prettier/prettier#13729

[michaelfaith]

Prettier 3.0 was released today: https://prettier.io/blog/2023/07/05/3.0.0.html

[michaelfaith]

Since trivago/prettier-plugin-sort-imports#171 was completed, does that mean this library is good to go for v3 compatibility?

[IanVS]

Thanks for the heads up. I think we might be compatible, but I haven't checked yet. Want to give it a shot?

[michaelfaith]

Preliminary tests I've run with our existing config looked good. What I haven't tested yet, but have on my to-do list, is to test with esm config.

[fbartho]

@michaelfaith we have a PR where we did the initial upgrade to one of the alphas: #75

See that PR for a discussion -- but unfortunately, we were broken for alpha.5 to alpha.11! (Haven't tested later than that).

[michaelfaith]

@fbartho thanks for the link. Running in an existing project with Prettier v3 and the latest release of this library worked ok without needing to change any config. It's possible we're not using an aspect of the library that's broken, if you're having trouble with it. I still need to test with esm config (we are using it on TS, SCSS, JS, HTML, MD mostly)

[michaelfaith]

Just tested with esm config and everything just worked.
Here's the config I'm using now:

import sortImports from '@ianvs/prettier-plugin-sort-imports';

export default {
  singleQuote: true,
  plugins: [sortImports],
  importOrder: [
    '', // Empty line
    '<BUILTIN_MODULES>', // Node.js built-in modules
    '<THIRD_PARTY_MODULES>', // Imports not matched by other special words or groups.
    '', // Empty line
    '^[.]', // relative imports
  ],
  importOrderParserPlugins: ['typescript', 'jsx', '["decorators", { "decoratorsBeforeExport": true }]'],
};

No errors. I shuffled my imports up just to verify that it wasn't failing silently or anything, and on the surface everything worked as expected.

[IanVS]

Cool, thanks! I'm going to close this issue then, and if anyone has troubles they can open a new one.