-
Notifications
You must be signed in to change notification settings - Fork 0
Remove detectEmbeddedLanguage
#1
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
Conversation
src/language-css/embed.js
Outdated
| return doc ? [doc, hardline] : ""; | ||
| return async () => { | ||
| const doc = await printFrontMatter(node, textToDoc); | ||
| return doc ? [doc, hardline] : ""; |
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 related to these PRs, but returning "" from here means that the usual print function will be called for this node. I wonder if this is intended.
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.
Yes, the usual print should be called. https://github.com/prettier/prettier/blob/765cae25522f582b71a79e7fb10417eb4612abe6/src/language-css/printer-postcss.js#L100, but better to return undefined/null as embed designed.
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.
BTW the plugin should always handle all node types in print, even if embed return a fallback doc, because we have embeddedLanguageFormatting option to skip embed.
src/main/multiparser.js
Outdated
| printer.detectEmbeddedLanguage?.bind(printer) ?? (() => true); | ||
| const { ignoredProperties } = printer.massageAstNode; | ||
|
|
||
| const pathStacks = []; |
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.
This variable needs a better name. embedCallResults?
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.
Yah, need more work, just testing if it works.
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 looks good. One more name idea: embedThunks
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 this 5c1a383 😄
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.
Doesn't look like it might work :)
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.
As we're breakingly changing the signature of embed anyway (the textToDoc parameter becomes async), I think we should simply forbid sync embeds, i.e. the return type should become undefined | () => Promise<Doc | undefined>.
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.
Corrently use sync embed in a few places.
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.
They can be sync, but they shouldn't use print in that case (because it's print that can try to get things from embeds that haven't become available yet). Should we probably remove print from the parameters of embed and pass it only to the returned functions then?
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.
they shouldn't use print in that case
When calling print in the returned function, it's still possible not settled? Visting siblings doc, for example.
Should we probably remove print
In that case, why not pass both print and textToDoc to the returned function, to prevent
const promise = textToDoc();
return () => promiseThere 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.
When calling print in the returned function, it's still possible not settled? Visting siblings doc, for example
I guess we should just say that it's a design limitation: print should be used only to print the current node's descendents.
In that case, why not pass both
textToDoc
👍
|
We are calling |
I wanted to do that, then decided to keep this change simple. |
|
In theory, |
|
Passed to where? |
|
No, I mean |
|
Embed doesn't take |
|
Let's go back to 05cc6d5 |
03db215 to
08c7dd9
Compare
|
Have you benchmarked this? |
Not yet. |
|
Pass options too? When checking languages, the printer may don't need that to make decision. |
We should treat if (language === "graphql") {
return formatGraphql;
} |
|
Does this order |
|
|
The |
Yep. Let me bring my second PC to run benchmarks on it :) |
|
No changes in performance compared to prettier#13211: |
docs/directory)changelog_unreleased/*/pr-XXXX.mdfile followingchangelog_unreleased/TEMPLATE.md.✨Try the playground for this PR✨