Comments are removed even with `minify: false`

[onigoetz]

I have seen that any input with comment is output without comments even when minification is disabled :

const css = require("@parcel/css");

const inputs = [
  "/* before */ rule { c: 1 } /*! after */",
  `/* before */
            rule { d: 1 }
            /*! after */`
];

inputs.forEach((input) => {
  const { code } = css.transform({
    filename: "",
    code: Buffer.from(input),
    minify: false
  });

  console.log({
    input,
    output: code.toString()
  });
});

Results in

{
  input: '/* before */ rule { c: 1 } /*! after */',
  output: 'rule {\n  c: 1;\n}\n'
}
{
  input: '/* before */\n            rule { d: 1 }\n            /*! after */',
  output: 'rule {\n  d: 1;\n}\n'
}

For most comments that shouldn't be a problem, but if the comment starts with /*! in general it should be preserved as it is used for licenses or other content that was specifically marked to remain in the code.

Is there a way to keep those comments ?

[devongovett]

Comments are ignored during tokenization, so it would be pretty difficult to preserve comments anywhere, but perhaps we could preserve comments at the start of a file. Would that work for your use case?

[onigoetz]

For the test I have it wouldn't but that seems like a reasonable tradeoff.

Except if a file that had a comment at the beginning was imported and it ends up in the middle of the file sent to @parcel/css 🤔

I have to say I don't know

[bakura10]

Hi,

For our use case, we would want to generate a final CSS that is aimed to be included inside themes. Keeping the comments are useful for developers working on top of our themes, as I often use the comments for providing technical info about my choices.

I think having a way to keep comments would be a nice addition, this is currently the only thing that block me to migrate to this tool :).

[kwangure]

We use comments to generate CSS Docs for custom properties. It helps keep implementation and documentation in sync.

[bakura10]

Is there any news on this @devongovett or way to prioritize this? :) It would be really nice if comments would not be removed here. This really serves as documentation for us, as we redistribute our source code as part of the themes we sell.

[devongovett]

I don't think this can be easily done with the current architecture. Parcel CSS is first and foremost a compiler and minifier, and is designed to produce output intended to be consumed by machines, not humans. If you want to do something like formatting (eg prettier), then another tool might be more appropriate.

Distributing code with docs sounds more like source code than compiled code to me. I would just publish the source code and let users compile it as they see fit. But maybe I'm missing something.

[bakura10]

Yes unfortunately this is not possible, we are selling on a platform where we need to ship a single file :). Anyway, I think I can deal with it !

[Cam]

Personally I think a config that allows comments to be preserved is important. There are many legitimate reasons for preserving comments in project production environments. Including legal obligations.

[toastal]

Many tools hold on to comments with /* @license xxx */ too. I would like this feature for legal reasons.

[contactjavas]

Keeping CSS comment is useful when developing WordPress theme. A theme requires a main style.css that provides the theme's identity. Well, we can just provide the main style.css that contains only theme identity like this:

/*
Theme Name: Theme name
Author: Someone
Description: A custom theme.
Version: 1.0.0
Text Domain: theme-name
Requires PHP: 8.1
Tested up to: 6.0
*/

And then watch / build the real styles in other file that doesn't require the theme's identity information.

It would be nice if there were an option to keep CSS comments. For people who would like to use Parcel when developing a WordPress theme, you can use style.css to provide the theme identity and other file for the real styling.

[ghost]

Our project generates an RTL CSS (using rtlcss) file based on the output CSS file. Inside our styles, we have directives like:

.myClass {
    /*rtl:ignore*/
    left: auto;
    ...
}

to skip some conversions. I replaced postcss with this plugin for autoprefixing but it's removing those directives, so I'm forced to switch back. I can still use the minification part of the plugin but I also really wanted to have the prefixing done by Lightning.

I hope you find a way to support such directives in the future, I'm a fan of what you all are doing here!

[devongovett]

License comments (denoted with /*! ... */ syntax) at the start of a file will now be preserved as of 5cec8beb1e8d14fb1818f220db3d9354b7405506. This style with the exclamation mark is also supported by other minifiers like cssnano and esbuild. Other comments in the middle of a file are still not preserved, as these are much harder to handle. But hopefully this solves a common need at least.

[mindplay-dk]

I'm having the opposite problem - parcel now seems to emit comments by default?

As you can see, my last build only had the license comments:

But after I upgraded Parcel, now I'm getting all sorts of inline comments:

installed versions

``` $ npm ls inertion@0.2.3 /home/mindplay/workspace/funky-test ├── @parcel/packager-ts@2.10.1 ├── @parcel/transformer-typescript-types@2.10.1 ├── @types/diff@5.0.7 ├── @types/validator@13.11.5 ├── ansi-colors@4.1.3 ├── diff@5.1.0 ├── fast-deep-equal@3.1.3 ├── jest-serializer-ansi-escapes@2.0.1 ├── nyc@15.1.0 ├── parcel@2.10.1 ├── pretty-format@29.7.0 ├── ts-node@10.9.1 ├── tsx@3.14.0 ├── typescript@5.2.2 └── validator@13.11.0 ```

Any idea what could be causing this?

[fzieris]

I'm having the opposite problem - parcel now seems to emit comments by default?

Any idea what could be causing this?

Apparently, we need to add a .terserrc file with the following content (got the idea from here: https://github.com/evanw/esbuild/commit/04b7e1e8f6f528d948c8bbcb68803471382b5570):

{
  "format": {
    "comments": false
  }
}

Documentation:

• https://parceljs.org/languages/javascript/#minification
• https://swc.rs/docs/configuration/minification#jscminifyformat

[mischnic]

But after I upgraded Parcel, now I'm getting all sorts of inline comments:

That is a bug in swc, it's already fixed but not released yet: https://github.com/swc-project/swc/pull/8257

[stanleyxu2005]

Instead of a boolean switch minify: bool, it'll be great, if there could provide a callback, to determine how to deal with comments.

Below is how cssnonos way to preserve license header in CSS file.

        minimizerOptions:
          // cssnano
          {
            preset: [
              'default',
              {
                // Keep license related comments (todo: move license comment to a separate file)
                discardComments: {
                  remove: (comment) => {
                    const keepMe = /^\**!|LICENSE|@preserve|@cc_on/i
                    return !comment.match(keepMe)
                  },
                },
              },
            ],
          },

[Codex-]

Would also love to see comments accessible to some degree, i.e.

transform({
  filename: "",
  code: Buffer.from(css),
  visitor: {
    CommentBlock(cmt) {
      console.log(cmt);
    },
  },
}),

So even if they don't necessarily make it to the output at this stage they could be handled in some way during transformation

In my use case I wanted to use comments to indicate which block I was in (as they're identified this way from an API) and capture the URL's, pairing these would have been perfect.

In saying that, really loving the transform API in general and how nice it is to use

[cossssmin]

Hi, just wanted to share another use-case where comments are important: HTML emails.

For example, Mailchimp templates use comments:

<style>
  /*
    @tab Page
    @section Body Background
    @tip Set the background color for the email body.
  */
  .wrapper {
    /*@editable*/background-color: #EEEEEE !important;
  }
</style>

Context: we use Tailwind CSS in Maizzle. Noticed this while testing out Tailwind v4 beta, which now uses Lightning CSS.