feat: add new css parser - postcss #1458
Conversation
|
| } | ||
| getSelectors(ast.stylesheet); | ||
| const mediaFeatures = css | ||
| .findAll(newAst, (node) => node.type === 'MediaFeature') |
There was a problem hiding this comment.
Possibly some further optimizations we could even make here by using the css.walk method to only traverse the AST once (rather than twice like I assume findAll is doing)
packages/rrweb-snapshot/package.json
Outdated
| @@ -1,6 +1,6 @@ | |||
| { | |||
| "name": "rrweb-snapshot", | |||
| "version": "2.0.0-alpha.13", | |||
| "version": "2.0.0-alpha.12", | |||
There was a problem hiding this comment.
Should probably be 13?
|
This is great and something I thought we might get to 'some day' after the recent fixes to css.ts. Would you be able to post a before/after of the built file sizes from this change; i.e.
One of the reasons css.ts was ported over was so that we could tree shake it a bit. |
|
Something isn't right here because I'm getting the same values when running
Before After |
|
In a significant update here I moved to using This massively simplifies the I've moved around some test files to better separate concerns. Some of the tests were "testing the framework" given they had been copied over from https://github.com/reworkcss/css/blob/master/test/parse.js. I removed any that were no longer relevant but left any of the cases added in https://github.com/rrweb-io/rrweb/pull/1440/files#diff-ca07555d1c1965f9c7ef3b5df3772a19953138b8eac62deb7786e549b25b455d as we know they've specifically broken in the past and we would like to avoid breaking them in the future |
|
Super! What sort of filesize numbers are there with the |
|
Sorry @eoghanmurray, probably wasn't clear but I updated my earlier comment with latest build numbers having run
|
eoghanmurray
changed the title
| @@ -9,6 +9,9 @@ import { | |||
| } from './types'; | |||
| import { isElement, Mirror, isNodeMetaEqual } from './utils'; | |||
|
|
|||
| // eslint-disable-next-line @typescript-eslint/no-unsafe-assignment, @typescript-eslint/no-var-requires | |||
| const postcss = require('postcss'); | |||
There was a problem hiding this comment.
I'm not familiar with the various import methods, but feel this needs a bit of an explanation as to why you are doing it this way
There was a problem hiding this comment.
This is causing tests to fail with require is not defined
There was a problem hiding this comment.
Is it that we need a typescript version of https://github.com/giuseppeg/postcss-pseudo-classes
?
There was a problem hiding this comment.
This require business might be fixed with this PR: #1033
There was a problem hiding this comment.
Thanks for the heads up @Juice10. I've been meaning to get back to this PR but have had some vacation recently. The good news is that this seems to have resolved all known CSS issues for us. I can hold off until the Vite changes are merged if that is imminent
|
Hopefully the following doesn't derail the conversation, and even if we go ahead with the following, that doesn't detract from the worth of the current PR... So okay I just had a thought; all this CSS processing is on the replay side, right? === edit: I've drafted this up in #1480 |
I don't think we can know that something has a permanent web presence only because it has a versioned URL - e.g. I was just dealing with a customer bug report that centred around the assets only living for 15 days and not inlining at capture We either need very robust inlining or asset capture at recording time (ideally both :)). Loading over the net back to the customer is only a fallback in a perfect world. (I appreciate that's a (this) consumer of the library position and not necessarily a developer of the library position 😊) |
|
Yes, this could be configurable, and likely a robust solution will involve deploy of your own proxy/cache for assets. We replicate the '.hover' modification server side in our proxy cache so applying those modifications at replay on all |
|
Rebase or merge of master needed: there is a new test in #1481 which adds coverage to the css parser; hopefully it will pass (or fail) as-is without having to modify the test itself. |
|
Also re. rrweb-snapshot/test/rebuild.test.ts if you revert the whitespace changes to the expected css, you could instead cherry-pick the following commit which should do loose matching by ignoring whitespace and semicolon: |
|
Let me know if you wish me to execute the above two for you. |
rrweb-snapshotparses stylesheets to adapt the CSS for playbackIn certain cases the parsing wasn't always correct:
PostHog/posthog#21427
#1379
Which led to improved CSS selector efforts first included in
rrweb@2.0.0-alpha.13(#1401)Sadly this caused playback issues that consumed 100% CPU and froze playback
PostHog/posthog#21791
CSS parsing is performed in the https://github.com/rrweb-io/rrweb/blob/master/packages/rrweb-snapshot/src/css.ts which was pulled from https://github.com/reworkcss/css (which hasn't been updated in over 3 years)
I propose moving to https://github.com/csstree/csstree which creates an actual AST which can be used to effectively debug via https://astexplorer.net
I couldn't figure out some import issues in the
test/integration.test.tsAll
test/css.test.tstests still pass which confirms this is as good as the trickiest cases previously handled without any of the slowness introduced in #1401