-
Notifications
You must be signed in to change notification settings - Fork 22
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
[prettierx] Yarn audit issues in transitive dependencies #587
Comments
I took a cursory glance at both postcss-scss and remark-parse. The upstream postcss fix is minor; we could easily backport it. The remark-parse situation is not so simple, however — since the last version affected by the trim dependency issue, the internals have entirely changed, and there are breaking changes in the API. The update will have to take place upstream. |
Do you mean that you can update If so, that would be really awesome. I think you can imagine that I would love to avoid merging more updates from their
Right, but at least they would be ahead of existing prettierX 0.18.1, maybe good enough. |
It is very likely that update will be safe. Maybe a few new warnings. |
I dug deeper: simply updating postcss-scss to 3.x breaks tests and behaviour:
The appropriate fixes were made upstream — but they are based on functionality in prettier/prettier#7933 that itself created breaking changes. As a result, as mentioned in prettier/prettier#9482 (comment), the update and related changes were reverted in prettier/prettier#9500. The implementation of the appropriate fixes upstream was delayed to 2.3 but got delayed again to 3.x (prettier/prettier#9584). |
Is it a valid CSS? |
@adalinesimonian I am thinking we could just cherry-pick prettier/prettier#7933 for now, maybe with some special marker comments to avoid losing these changes when we finish the merge from upstream Prettier 2.3.1. And minor "breaking" changes are fine since prettierX is still pre-1.0. @ai I hope you don't think we see an issue with PostCSS itself, we are dealing with the brittleness of this whole software fork. Thanks for your input. |
Definitely not. In prettier/prettier#8675 (comment) it was decided that this semicolon is fine since the code is invalid anyway. I'm not sure why the second pass of format is adding an additional semicolon, however. As it stands this would result in prettier adding semicolons over and over again to an invalid line. I don't mind invalid code being invalidly formatted, but I would rather us not have compounding changes to files when formatting. Nonetheless, this seems to be something on prettier/prettierX's end, not an issue with postcss.
I agree that we don't have an issue with breaking changes at this stage in the project. At the moment, I'm trying to see if there's a simpler fix, first, before bringing in a larger number of changes from upstream. |
Regarding the issue with the compounding semicolons, I've narrowed down the change in behaviour in the parser. Here's the input line: @import ur
l(//fonts.googleapis.com/css?family=Open+Sans:400,400italic); The AST from postcss-scss 2.x is (with extra details redacted): {
"raws": { // semicolon is false even though line ends with semicolon
"semicolon": false,
"after": "//fonts.googleapis.com/css?family=Open+Sans:400,400italic);\n"
},
"type": "root",
"nodes": [
{
"raws": {
"before": "",
"between": "",
"afterName": " "
},
"type": "atrule",
"name": "import",
"params": "ur\n l("
}
]
} The AST in 3.0.5 is identical.
@import ur
l(; //fonts.googleapis.com/css?family=Open+Sans:400,400italic); The formatted line results in the following AST in postcss-scss 2.x: {
"raws": { // semicolon is now true
"semicolon": true,
"after": "\n"
},
"type": "root",
"nodes": [
{
"raws": {
"before": "",
"between": "",
"afterName": " "
},
"type": "atrule",
"name": "import",
"params": "ur\n l("
},
{ // the contents of the rule are now parsed as a node
"raws": {
"before": " ",
"inline": true,
"left": "",
"right": "",
"text": "fonts.googleapis.com/css?family=Open+Sans:400,400italic);"
},
"type": "comment",
"text": "fonts.googleapis.com/css?family=Open+Sans:400,400italic);"
}
]
} However, the AST outputted by 3.0.5 differs: {
"raws": { // semicolon is false even though last child node ends with semi
"semicolon": false,
"after": " //fonts.googleapis.com/css?family=Open+Sans:400,400italic);\n"
},
"type": "root",
"nodes": [
{
"raws": {
"before": "",
"between": "",
"afterName": " "
},
"type": "atrule",
"name": "import",
"params": "ur\n l(;" // last child does have a semicolon
}
]
} No matter how many times you add a semicolon, The line that adds the unwanted semicolon in this case is https://github.com/prettier/prettier/blob/2.3.1/src/language-css/printer-postcss.js#L304 if anyone wants to take a look at it. I'm signing off for the day. |
I am now thinking to move the |
Many thanks to @ai for updating PostCSS v7. I hope Prettier will make a stable version with prettier/prettier#9584 (PostCSS updated to v8) in the near future. Side question to @adalinesimonian and @ai if you both speak Russian? I do not but have met many Russian speakers over the past couple decades. |
Я говорю |
remark-parse drives all markdown functionality - if we make it optional, I doubt that almost anyone would opt to not install it, seeing as virtually every JS project has at least a few markdown files lying around. That said, I'm not opposed to putting it into peer deps; instead, I'm not confident that it would change much practically. Do we have any metrics on the use of prettierX that would be useful?
@ai rocks, thank you so much for the one-time exception. I'm looking forward to Prettier updating to 8.x so that we can pull down their changes into this fork and resolve this issue for good — this certainly won't be the last time a postcss dependency has a vulnerability.
Да, знаю русский! Funny enough, yes — I grew up in a multi-lingual household; I've got middle eastern and white ancestry. The common language between my parents was Russian, so I grew up with it. |
😄 My mothers family which is Jewish left Lithuania in the 1800s which I think you know was part of the Russian empire at that time :) I think I have good news for prettierX:
|
It's a small world out there; my mom's family is Jewish and Russian.
Sounds great! I'm a bit occupied this week, but I'll have a little bit of time tomorrow morning and Thursday/Friday morning to be available to work on any aspect of the project. Let me know how I can help, and I'll be glad to do it. |
Shalom @adalinesimonian that is so cool:) I have now switched to I did try regenerating I am now thinking it would be most straight-forward to make the
Thanks, I will comment in PR #569. |
Happy to report that in #569:
|
Yeah thanks!! I have made the new release with updates from Prettier 2.3.2, with many of the updates proposed in PR #603. I sincerely hope that they will find a way to resolve these warnings in the upstream Prettier repository. |
Just to clarify:
|
outdated- no longer an issue with npm installation due to recent [email protected] update; however PostCSS v8 update is needed since PostCSS v7 will no longer be supported ref: Advisory for v7 postcss/postcss#1574postcss
via outdatedpostcss-scss
dependency - https://npmjs.com/advisories/1693outdated- now resolved by PR [WIP] prettierx-update-branch-001 - UPDATE WIP #593trim
via outdatedremark-parse
dependency - https://npmjs.com/advisories/1700should be resolved by proposed update from Prettier 2.3.1 in PR #569Updates:
next
branch of Prettier: Build(deps): Bump postcss-less from 3.1.4 to 4.0.0 prettier/prettier#9471, Updatepostcss-scss
prettier/prettier#10490remark-parse
is still outdated in thenext
branch of Prettier, and it is not a simple update without using @brodybits fork (see comment below).P.S. While I do not expect these issues to have much of any real-world impact in the near term, I would like to get these resolved asap.
/cc @adalinesimonian @aMarCruz @ai
The text was updated successfully, but these errors were encountered: