Skip to content
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

perf(css): hoist at rules with regex #7691

Merged
merged 3 commits into from Apr 12, 2022
Merged

Conversation

bluwy
Copy link
Member

@bluwy bluwy commented Apr 12, 2022

Description

When hoisting the at rules, use regex instead of postcss to do so for speed and reduced memory comsumption.

Additional context

Noticed this additional optimization in #7678

Did some simple benchmarking on a concatenated 455KB css file.

Before: 202.29ms
After: 15.519ms

More than 10x faster (could be more on large file size)


What is the purpose of this pull request?

  • Bug fix
  • New Feature
  • Documentation update
  • Other

Before submitting the PR, please make sure you do the following

  • Read the Contributing Guidelines.
  • Read the Pull Request Guidelines and follow the Commit Convention.
  • Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
  • Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
  • Ideally, include relevant tests that fail without this PR but pass with it.

@bluwy bluwy added feat: css p2-nice-to-have Not breaking anything but nice to have (priority) labels Apr 12, 2022
Copy link
Member

@poyoho poyoho left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. And some nitpicking advice

// CSS @import can only appear at top of the file. We need to hoist all @import
// to top when multiple files are concatenated.
// match until semicolon that's not in quotes
s.replace(/@import\s*(?:"[^"]*"|'[^']*'|[^;]*).*?;/gm, (match) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@import /* comment; */ url( "baz") /* com;ment */; @import seems to support comments, will break the match.

I just found out that there is also a border issue. "word\"" 🙈

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those are real edge cases 🥲 It looks tricky to use emptyString() with MagicString.replace though, and doing so would make another copy of the string, which brings in some memory overhead. I feel like we could ignore them for now since there are unlikely to be instances of this in practice.

Otherwise, it may be simpler to go back to the postcss way 🤔

Copy link
Member

@poyoho poyoho Apr 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes this edge case, but if you want to avoid it, you can use the following code. 😊

s.replace(/@import\s*(?:"[^"]*"|'[^']*'|[^;]*).*?;|\/\*(.|[\r\n])*?\*\/|\/\/.*/gm, (match) => {
  if (match[0] === '/') return match
  ...
})

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried the regex and MagicString doesn't seem to like it: Cannot split a chunk that has already been edited (0:38 – "/* semicolon; */"). We may have to resort to not using .replace if we want to robust-ify the regex.

@patak-dev
Copy link
Member

@bluwy I think we could merge this one and run vite-ecosystem-ci, so we don't need to wait until 3.0. What do you think?

@sapphi-red for later, we are missing sourcemaps handling here, no? (not in the new code, it was already missing sourcemaps)

@bluwy
Copy link
Member Author

bluwy commented Apr 12, 2022

Yeah I think this is safe to merge now. Re sourcemaps, we're definitely missing them here, luckily magicstring makes it easy to do so too.

@sapphi-red
Copy link
Member

Yes, sourcemaps are not handled here.
This part only runs during build.
So it needs to be handled when css sourcemaps during build is going to be supported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat: css p2-nice-to-have Not breaking anything but nice to have (priority)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants