parcel-bundler / parcel-bundler/lightningcss

Merging adjacent rules with *almost* the same declarations

Open
#271 3 comments 12 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

area: minification
Dominant language
Rust
Stars
7.7k
Forks
302
PR merge metrics
No merged PRs in 30d

Description

README says:

Merging adjacent rules with the same selectors or declarations when it is safe to do so.

This works as advertised:

.foo {
    background-color: red;
}
.bar {
    background-color: red;
}

/* output */
.foo,.bar{background-color:red}

But I wonder, is there any reason not to merge partially-indentical rules?

.foo {
    background-color: red;
    padding: 20px;
}
.bar {
    background-color: red;
    padding: 40px;
}

/* actual output */
.foo{background-color:red;padding:20px}.bar{background-color:red;padding:40px}

/* better output? */
.foo,.bar{background-color:red}.foo{padding:20px}.bar{padding:40px}

/* or maybe even: */
.foo,.bar{background-color:red;padding:20px}.bar{padding:40px}

Or am I wrong to think that as long as the rules are adjacent, this should be safe to do?

(The gains aren't big in this simplified example, but we have CSS with long adjacent rules that differ in only one or two declarations, and it quickly adds up.)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue provides CSS examples but names no implementation files, tests, or entry points. First determine whether partially identical adjacent rules can be merged without changing CSS semantics, then establish the intended output and add regression coverage for the chosen behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
css, rust
Domain
compilers, performance
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.