Discussion: would less broad activation events make sense?

[Cube707]

Is your feature request related to a problem? Please describe.

This extension will startup always, even on workspaces that contain projects where prettier can not do anything. For example, I have several Python and C/C++ Projects where prettier also starts even when not needed.

Describe the solution you'd like

The activation events onLanguage, workspaceContains and onCommand could be used to have this extension start only when it actually makes sense (so on the actually supported languages, when a .prettierrc is present inside the workspace, when a command from this extension is used, etc.)

Describe alternatives you've considered

One can of course disable the extensions for certain workspaces or only enable it when needed. But I think it is worth discussing, if an "automagical" workflow would be a desired feature

[ntotten]

Yeah, this would definitely be desirable, but the last time I looked into this it wasn't possible to do it correctly with the current API of VS Code. Its been a while since I looked at this so I can't remember exactly, but it was something to do with how languages are registered with prettier and vscode. I'd be happy to take a PR if things can be improved without loss of funcationality.

[Cube707]

I am gonna start to collect some infos here. I am not very familiar with prettier and have only used it in a couple of projects, so it's probably incomplete.

From my first dive into https://code.visualstudio.com/api/references/activation-events I belive the following aktivation events would be sensebile:

• onCommand this one is obvious, whenever a command from this extension is requested, it needs to start up
• workspaceContains this allows us to put glob-patterns for files that should start up this extention
• onLanguage is gonna be the complex one

what commands exist?

I only identifyed two commands, so these activation events should handle that:

• "onCommand:prettier.createConfigFile"
• "onCommand:prettier.forceFormatDocument"

which files are specific enough?

To catch wird edgecases (where VScode doesn't jet register a filetype for whatever reason) and just for user-convinience the extention should start when a projectly obviouly uses prettier, but how to identify this: .prettierrc and .prettierignore are two obvious and easy candidates, but maybe there are more I don't know about??

• "workspaceContains:.prettierrc"
• "workspaceContains:.prettierignore"

also it would need to be tested and discussed if only toplevel files are relevant or if we should also check subdirectorys for these files and if we need to change to "workspaceContains:**/.prettierrc"

what languages are relevant?

This is the list of languages prettier supports, at least what I could find. Where I could find you what language identifyer it maps to inside VScode, I added the corisponding language identifyer:

• [x] JavaScript: "onLanguage:javascript"
• [x] TypeScript: "onLanguage:typescript"
• [x] JSX: "onLanguage:javascriptreact"
• [x] "onLanguage:typescriptreact"
• [x] JSON: "onLanguage:json" and "onLanguage:jsonc"
• [x] CSS: "onLanguage:css"
• [x] SCSS: "onLanguage:scss" and "onLanguage:sass"
• [x] Less "onLanguage:less"
• [x] HTML. "onLanguage:html"
• [ ] Angular HANDLEBARS: probably handled as HTML??
• [x] Vue: "onLanguage:vue" and "onLanguage:vue-html"
• [x] Markdown: "onLanguage:markdown"
• [x] YAML: "onLanguage:yaml"

I don't know this languages, so I don't know if they are allready coverd/how VScode handles them

• [ ] Flow
• [ ] Ember
• [ ] Glimmer
• [ ] GraphQL

and what about plugins?

And than the question, how we should handle plugins? I think that in those cases a .prettierrc will be present, so we are fine, but maybe not?

[github-actions[bot]]

This issue has been labeled as stale due to inactivity. Reply to keep this issue open.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.