New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use a monorepo and separate out Prettier’s components #3511
Comments
I think there are significant advantages to sticking to one installable on npm for "core prettier" things (everything in this repo), but being able to plug Prettier with new parsers and printers is valuable. I've been toying around with a refactor sketch to force an API on the doc-builders and co. Feedback appreciated! Directory Structure
Language Plugin APIEach of the
Additionally they will export
Configuring Language PluginsModule names will be resolved using Node.js module resolution, so both absolute and relative paths will work. .prettierrc: {
"plugins": ["prettier-ruby", "./prettier-csharp"]
} CLI prettier --plugin prettier-ruby --plugin ./prettier-csharp --write We could go one step further and use lerna, converting each of the above directories in |
Why does Prettier bundle its dependencies? It would make more sense IMO to have both the Prettier core and Prettier plugins |
To be fast? |
Here's some reference: #735 |
And here too: #1640 (comment) |
@azz I liked the language plugin API, I didn't understand the configuration part. Why is that necessary? Community plugins? |
Yes, only need config for separate packages. |
In that case, can we force lazy loading the parsers (or expose hooks for when to load) on those unofficial plugins? |
They'd be loaded at the same time a regular parser will be loaded, the resolution will just be different. |
I'm going to have a crack at this over the next couple of days. |
@azz I mean nothing will prevent someone from including a
Nice! Let me know if you need help, I've started some experimenting with loading parsers for #3296 but this should unblock that anyway :-) |
Need a way for a plugin (e.g. our own javascript support) to support multiple parsers that map to one printer. E.g. we have parsers:
And soon Which all output a similar AST. We have two "languages" here: All of them map to the same printer. (let's call it Could it look something like this? export const languages = [
{
name: 'javascript',
// first would be the default?
parsers: ['babylon', 'flow'],
astFormat: 'estree',
},
{
name: 'typescript',
parsers: ['typescript-eslint', ['babylon', { extraPlugins: ['typescript'] }]],
astFormat: 'estree',
},
];
export const parsers = {
babylon: parseWithBabylon,
flow: parseWithFlow,
'typescript-eslint': parseWithTsep,
};
export const printers = {
estree: {
print: printAstToDoc,
embed: embedFromEstree,
},
}; Then we can support a generic |
👍 That API looks pretty cool. Also, if I were to make my own JS variant, I could do something like this: export const languages = [
{
name: 'sumatrascript',
parsers: ['sumatra'],
astFormat: 'estree',
},
];
export const parsers = {
sumatra: parseWithSumatraScript,
};
// no printer needed! |
I agree with this, but I think JS/TS/Flow can live under a single |
Setup two new repos successfully using this API 💥 |
Thoughts on using scoped vs non-scoped packages ( |
I think the scoped packages should be used for official (in the @prettier org) plugins, whereas community members would be able to use the |
Sounds good. Looks like |
Awesome! Published the two plugins: prettier/plugin-php#9 & prettier/plugin-python#16. |
Should we be renaming the repositories?
|
I think all the other packages should go under the org too, but not as a scoped one 🙂 |
It's one less step for people cloning the repo if it's |
This comes from the Prettier 2.0 issue
@j-f1:
@azz:
@lydell:
@j-f1:
@TrySound:
@lydell:
@duailibe:
@j-f1:
@duailibe:
The text was updated successfully, but these errors were encountered: