Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add Document node and related API (#1498) #1582
Add Document node and related API (#1498) #1582
Changes from 6 commits
eb896ce
aa25ce0
39d2a84
fca648b
da90932
a5ac723
69c5d81
50e07d1
49eec3a
54e2e52
3eb068b
8af26ab
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Should we move it to
Node
generic too? And useNode<Parent extends Node = Container>
,Container<Child …, Parent …> extends Node<Parent>
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 have no luck with this due lack of experience working with generics and classes. When added
<Parent extends Node = Container>
toNode
class, then visitor test shows type errors. ForContainer
I couldn't get past error inContainer
type.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.
Don’t worry. I will try to fix it after merging PR.
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.
If
Document
has noraws
, how we will track symbols after the last style?Should we add
Document.raws.after
? It will fitAtRule
andRule
way to keep last symbols.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 have in mind that
Root.raws.before
andRoot.raws.after
are used:postcss/test/stringifier.test.js
Lines 266 to 286 in a5ac723
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.
Hm. I am worried that it is a different way to take deal with spaces compared to
Rule
/AtRule
.But on another hand, we already have
Root.raws.after
.Do you think that the
Root.raws.after
is better?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.
Current state
Rule
/AtRule
treatbefore
as string before the rule.after
is a string after the last child node.Root
doesn't usedbefore
in default parser.after
is a string after the last child node.Name
after
is confusing, because it doesn't do opposite ofbefore
. It should have beenafterLastChild
:)First idea
I think if we want to keep the same approach to
before
(string before the node) andafter
(string after the last child of the node), we would need to addRoot.raws.before
, andDocument.raws.after
.Root.raws.before
is already added in this PR,Document.raws.after
is missing.For the following HTML:
We would have following AST:
In this examples Root boundaries would be content between
style
tags. As if we took this content and put it in a separate CSS file and parsed.Second idea (a better one, in my opinion)
After writing above, looking at the AST, and some thinking... I think this is all wrong :)
postcss/lib/node.d.ts
Lines 144 to 150 in ab60e0d
Adding
Root.raws.before
and using it not for spacing could potentially be a breaking change. E. g. some plugin looks into every node'sraws.before
and remove spaces. Then ifbefore
for parsed HTML would contain some HTML markup stringified output would be broken.This is what I think is what we need to have. Due to differences what parsed document could be (HTML, JS, TS, Markdown, vue, etc) we should not change any
raws
. So revertRoot.raws.before
in this PR.Document.raws
should be in types, but no specifics (any
).Every syntax will put whatever they want in
Document.raws
, and inRoot
could use any new key.Idea is to keep Root the same as if PostCSS default parser would create it, but we could add new
raws
keys with names, that PostCSS doesn't use.Here how I would make HTML parser:
If we remove
markupBefore
andmarkupAfter
it would be regular CSS and any plugin will work as expected.So custom syntax will create these new
raws
and then used them for stringifying.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.
Is it about first or second idea?
I like it more, but with
codeBefore
andcodeAfter
instead ofmarkup
, since we will not have markup in CSS-in-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.
I think first idea is a bad one.
In second idea raws names are up to developer of a syntax, because PostCSS wouldn't do anything with it. But I think your names for raws are better :)
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. Change the
raws
and we are ready to merge.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 removed
Root.raws.before
Added
raws
forDocument
and decided to test custom syntax withDocument
. This revealed that some types need to be adjusted. Also it helpful to have at least one test with syntax which works withDocument
:)