New comment polluting compiled CSS output

Package

@carbon/type

Browser

No response

Package version

10.35.0

Description

As part of PR #9480, comments like the following have been added to some SCSS files:

The problem is that this style of comment, /* ... */, in sass means that the comment is preserved into the CSS output, meaning that the output CSS from our builds now contains many hundreds of copies of this comment and have become substantially larger as a result. These comments only apply at build/lint time and do not need to be preserved into the CSS output. They should be changed to // ... style comments, which are discarded during sass compile.

@tw15egan @joshblack FYI

CodeSandbox example

no

Steps to reproduce

n/a

Code of Conduct

• I agree to follow this project’s Code of Conduct
• I checked the current issues for duplicate problems

[dcwarwick]

Agreed – bloat to the non-minimised built CSS is unfortunate but not otherwise a major issue in itself. I think I was more concerned that these comments simply do not belong in the generated output, so it’s a mistake, albeit an ultimately harmless one. I probably shouldn’t have used the “bug” tag, just a dev issue.

Our tests showed up the issue, but once we’ve regenerated the snapshots they continue to pass – although we do have one test that checks that a whole set of “definitions-only” SCSS generates no actual CSS output, and I have had to modify that test because although it still generates no actual CSS it does now generate some comments! I fixed that test by switching to use a minified CSS compile for the test, which does indeed slow the test down slightly. Not a big problem, though, and no ultimate impact on any production use cases.

[joshblack]

@dcwarwick great point on the codebase, I’ll definitely look into it and see 👀 thanks for pointing that out.

What are you seeing in terms of the impact of the size for uncompressed output? It seems like you’re using it for tests, is it that the tests are now slower, or is some other factor coming into play? In general, size of uncompressed output is not something we generally consider a bug but if you’re noticing something negative that is impacting a production use-case or a common use-case I’d love to know about it so we can make sure we consider it in our work 👍