search

zgreen / postcss-critical-css

PostCSS plugin to define and output critical CSS using custom atRules, and/or custom CSS properties. Critical CSS may be output to one or more files, as defined within the plugin options or within the CSS.
MIT License
86 stars 11 forks source link

Each at-rule overwrites the previous pointing to the same output file (Webpack 4) #47

Open bitfella opened 5 years ago

bitfella commented 5 years ago

Hello, I guess this could be related to #27.

I am using postcss-critical-css with Webpack 4 (Windows 10) and I am facing the following issue: when importing in the same JS entrypoint several scss partials containing critical at-rules pointing to the same output file, seems like the generated css carries just the contents from one of the sources (usually the one from the last saved source file). Each at-rule overwrites the previous. Sometimes partial overwrites could happen as well, generating syntax errors in the output.

This happens for static scss imports and for dynamic imports of JS files carrying scss imports, as well.

See this repo for further explanation.

Thanks

zgreen commented 5 years ago

Thanks for the bug report, and repo with the replication. It does sound like there's a bug here. I'll take a look as soon as I can; PRs welcome, in the meantime. Cheers.

bitfella commented 5 years ago

@zgreen thanks for your quick reply. Please be aware that @ostowe's own fork should solve this issue. I've tested it locally and everything seems to work fine. Please have a look at his PR #27 :)

Thanks!

RickKukiela commented 3 months ago

HI!

I just ran into a similar issue with my setup. I'm using Gulp5 streams process sass to css.

I have different scss @import files that have @critical file-name.css blocks and the resulting output file is corrupted exactly where the first block ends and the other block starts.

Essentially I get something that looks like this:

    ...
    top: 13%;
    left: 15%;
  }2.185em;
    font-weight: var(--fw-normal);
    line-height: 1em;
    ....

As you can see, the actual selector is missing. However, there are about two other selectors sets with rules that should have been included. Here is what was in the 2nd scss file that was missed:

main.landing-page {
    width: 1080px;
    margin: 0 auto;
    font-size: 15px;

    .font-light {
        font-size: 2em;
        text-align: center;
        font-weight: var(--fw-light);
        line-height: 1em;
        margin-bottom: 32px;
    }

    .font-reg {
    font-size: /* 2.185em (this bit was included in output) */

You can see where the parent selector had it's last rule as font-size and the first rule in where the break occurred is also font-size so I'm not sure if that's a clue...

The final output should have looked like this:

    ...
    top: 13%;
    left: 15%;
  }
  /** START MISSING **/
  main.landing-page {
    width: 1080px;
    margin: 0 auto;
    font-size: 15px;
  }
  main.landing-page .font-light {
    font-size: 2.00em;
    text-align: center;
    font-weight: var(--fw-light);
    line-height: 1em;
    margin-bottom: 32px;
  }
  main.landing-page .font-reg {
    font-size: 2.185em;
    font-weight: var(--fw-normal);
    line-height: 1em;
    letter-spacing: -0.03em;
  }
  main.landing-page .font-bold {
    font-size: /** END MISSING **/ 2.185em;
    font-weight: var(--fw-normal);
    line-height: 1em;
    ....

I see there is PR that might fix this issue, however, that PR is very old and it very behind the main code base. The PR was also never merged.

So is this a known issue that is not planned for resolution? Or was this supposed to be fixed via other means and I just found out that it's not fully resolved?