Unreliable order of plugins listed under options.plugins

[ArnaudBarre]

I have my configuration in my package.json with "plugins": ["@prettier/plugin-xml"] and the CLI errors src/icons/trash.svg: UndefinedParserError: No parser could be inferred for file

[fabiospampinato]

Plugins have not been wired back at the moment, it's maybe the main thing missing.

For use cases like yours it should be easy to get them to work, but for dynamically defined plugins, like via .prettierrc.js files, it may be much more difficult in general, maybe some things should be changed there for performance.

[fabiospampinato]

@ArnaudBarre In the latest alpha plugins should be supported, unless you pre-instantiate them in a *.{js|cjs|mjs} file, which I'd imagine most people don't do. Could you check if it works for you?

[ArnaudBarre]

Nope not working for me with 0.2.1

arnaud@Mac carbon-calculator-main % bun prettier --write '**/*.{ts,tsx,js,html,css,json,md,yaml,prisma,svg}'
[error] prisma/schema.prisma: UndefinedParserError: No parser could be inferred for file "/Users/arnaud/git/carbon-calculator-main/prisma/schema.prisma".
[error] src/components/PublicPageWrapper/graphic.svg: UndefinedParserError: No parser could be inferred for file "/Users/arnaud/git/carbon-calculator-main/src/components/PublicPageWrapper/graphic.svg".

My config in package.json (correctly resolved I tried to update printWidth):

{
  "prettier": {
    "xmlWhitespaceSensitivity": "ignore",
    "plugins": [
      "@arnaud-barre/prettier-plugin-sort-imports",
      "@prettier/plugin-xml",
      "prettier-plugin-prisma"
    ]
  },
}

[fabiospampinato]

Ah sorry it looks like I had only implemented it when configured entirely through the CLI, there are a bunch of extra things to take care of for your use case.

[fabiospampinato]

@ArnaudBarre could you check if alpha8 fixed all the issues for you?

[ArnaudBarre]

So now it works for SVG/prisma, but the new CLI makes options.plugins a lot longer with items likes

  {
    "parsers": {
      "acorn": {
        "astFormat": "estree"
      },
      "espree": {
        "astFormat": "estree"
      }
    }
  },

I don't think this is part of the plugin API and I don't mind updating my hacky code, just wanting to let you know in case it might be an unwanted change

[fabiospampinato]

Do you get a "Non-string plugin specifiers are not supported yet" error if you just don't change your configuration at all?

[ArnaudBarre]

Nope I get TypeError: Cannot read properties of undefined (reading 'estree') because the first item of the list is not anymore the main plugin with all the config and is the one in the previous comment

[fabiospampinato]

So it's probably an error 🤔 I'm not sure I'm understanding the scenario exactly though, does the previous repro that you made reproduce this?

[ArnaudBarre]

You should be able to reproduce the issue by running the latest version with https://github.com/ArnaudBarre/prettier-plugin-sort-imports on a simple TS file.

[fabiospampinato]

I've taken a closer look at this last error you hit, I think I would basically classify it as user error, because here you are making the assumption that the first plugin is going to be a specific one, basically, while that seems an implementation detail with no specific guarantees, so you shouldn't rely on that.

I see a couple of other projects potentially making the same assumptions, but presumably most users would be unaffected.

There could be more to this potentially, Prettier internally seems to use a function for generating a sort of single merged plugin which points to all the built-in plugins, and that's what you are referencing with that options.plugins[0], it's possible that doing it differently could break something else, but for now I don't see any actual clear errors in the current implementation in that regard.

[fabiospampinato]

Ah it's basically a performance optimization that Prettier is doing, to lazy-load built-in plugins as needed, which I actually wanted to do also but didn't know how to do it. I guess I can implement that and that should also accidentally fix your use case.

[fbartho]

@fabiospampinato — I personally would think that assuming plugins[0] is a specific problem is brittle/naive.

I would however expect that plugins are in a linear order. If you wanted to say “instead of accessing .plugins you should request plugins by id or provide use afilter method that matches for the plugin you need”, I think that would be fine.

Eg.

let esTreePlugin = options.plugins.findFirst((plugin)->{
  return plugin.estree != nil
}
…

[fabiospampinato]

closing as this commmit kinda accidentally fixes this, by loading built-in plugins ~exactly like the stable CLI does it.

I'll take a look at #5 and I'll try to push another release 🙂

[fabiospampinato]

@ArnaudBarre As soon as somebody is able to release -beta.0 you should be able to check for yourself if it fixes your problem or not. Sorry for the long wait, lots of things going on 🤪

[ArnaudBarre]

Yeah no problem, thanks for your work!