-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Prettier Plugin API #3536
Prettier Plugin API #3536
Conversation
src/builder/util.js
Outdated
node && | ||
node.comments && | ||
node.comments.length > 0 && | ||
node.comments.some(comment => comment.value.trim() === "prettier-ignore") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI [].some(() => true) === false
, so node.comments.length > 0
is not needed other than for explicitness.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True. I just moved this code though 😉
Managed to extract all the generic printing logic from the old Test failure
|
Any idea what happened to this job? https://travis-ci.org/prettier/prettier/jobs/319135394 |
src/main/parser.js
Outdated
}, | ||
get markdown() { | ||
return eval("require")("./parser-markdown"); | ||
return eval("require")("../language-markdown/parser-markdown"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In bundled version: Cannot find module '../language-markdown/parser-markdown' from 'index.js'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I'll be moving the output too eventually. Will have to upgrade the playground too.
As of 35c57c6 Prettier uses the plugin API internally! 🎉 Still have to get the build green (1 failing multiparser test remains), but should be good to review now. |
Why do the language files use |
It's a gross hack to prevent Rollup from bundling in the parsers. I'm just moving it from the |
bin/prettier.js
Outdated
@@ -2,4 +2,4 @@ | |||
|
|||
"use strict"; | |||
|
|||
require("../src/cli").run(process.argv.slice(2)); | |||
require("../src/cli/cli").run(process.argv.slice(2)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about src/cli/index
?
src/language-markdown/index.js
Outdated
get parse() { | ||
return eval("require")("./parser-markdown"); | ||
}, | ||
astFormat: "remark" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
src/main/doc-to-string.js
Outdated
@@ -1,7 +1,7 @@ | |||
"use strict"; | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
main/doc-to-string
-> builder/doc-printer
?
I think they should be in the same group since they are parts of the core printer, just like a standalone package.
doc-builders
doc-printer
doc-utils
fast-path
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea. Renamed it to doc
to make it a more cohesive package name. Moved out fast-path as it doesn't really belong.
Need to move FastPath#needsParens
to a separate file in language-js
I think.
We probably need to split out more things to be language-specific, e.g.
|
Markdown: <!-- @format --> GraphQL: # @format |
That's already a bug. If you use Edit: Raised #3557 |
Getting this error on the production build... Feel like I've seen it before...
|
|
||
return null; | ||
|
||
function getParserName(lang) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems we can re-use the support info (langName/extName) to get the correct parser? and it'll work with all external plugins.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea! Done.
package.json
Outdated
@@ -47,6 +47,7 @@ | |||
"postcss-values-parser": "1.3.1", | |||
"remark-frontmatter": "1.1.0", | |||
"remark-parse": "4.0.0", | |||
"resolve": "^1.5.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1.5.0
😂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not again... (at least the script catches it :D)
Looks like there's a Rollup bug. Any ideas? |
|
||
const externalPlugins = options.plugins.map(plugin => { | ||
const pluginPath = resolve.sync(plugin, { basedir: process.cwd() }); | ||
return eval("require")(pluginPath); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if there's any way this could support some sort of CLI-based API in addition to the JS ones, say some standard CLI commands that return information as JSON.
Doing so could allow writing Prettier plugins in languages other than JS, which would allow better integration for other language ecosystems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hypothetically, yes. But it would require an RPC interface to call the various functions (print
, embed
, parse
, etc)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not RPC per se since there's no remote ;)
Just like:
$ prettier-python parse <whatever>
Really this is all around prettier/plugin-python#2.
…3563) There's a lot of demand for vue sfc (#2097). This introduces partial support for them: all the html is printed as is, except for the script and style tags which are printed using prettier. I believe that this should cover a lot of the use cases while being simple to support and if we want we can extend to more in the future. I copy pasted the html parser used by vue (it's just a single 400 lines file) so that we don't run the chancesof conflicts. I'm also very conservative: I only print the style and script at the top level and for the lang attributes we support. I expect this to be landable as is and provide value, review welcome :)
50ad50e
to
5a10c03
Compare
🎄 ✅ Build is green! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So good! Thanks a lot for driving this, it has been a long time coming now that we support every language on earth to have a proper way of splitting them up :)
With the current implementation, can plugins add their own CLI options? At a glance, it looks like "no" – I think we'd need to do option parsing in two passes – first load the plugins, then load the config options for each plugin. |
Maybe just recommend using a config file for options? I'm happy to look at supporting CLI option contributions if it is easy to implement though. |
See https://github.com/prettier/prettier/pull/3584/files#r158743435 – it's not quite sufficient because if the option is unrecognized,
So even adding stuff to config files, disregarding anything like validation, is not sufficient. So unless I'm missing something ATM there's no actual way to configure plugins. |
Very early progress -
I've only moved files so far. Want to keep the build green and get as much feedback as possible on this one.Closes #3511
Follow ups (2.0 items):