-
Notifications
You must be signed in to change notification settings - Fork 167
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
Comments are removed even with minify: false
#43
Comments
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? |
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 |
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 :). |
We use comments to generate CSS Docs for custom properties. It helps keep implementation and documentation in sync. |
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. |
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. |
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 ! |
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. |
Many tools hold on to comments with |
Keeping CSS comment is useful when developing WordPress theme. /*
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. |
Our project generates an RTL CSS (using .myClass {
/*rtl:ignore*/
left: auto;
...
} to skip some conversions. I hope you find a way to support such directives in the future, I'm a fan of what you all are doing here! |
License comments (denoted with |
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
Any idea what could be causing this? |
Apparently, we need to add a {
"format": {
"comments": false
}
} Documentation: |
That is a bug in swc, it's already fixed but not released yet: swc-project/swc#8257 |
Instead of a boolean switch Below is how 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)
},
},
},
],
}, |
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 |
I have seen that any input with comment is output without comments even when minification is disabled :
Results in
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 ?
The text was updated successfully, but these errors were encountered: