Skip to content
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

Add option to don't drop comments #221

Closed
timocov opened this issue Jul 4, 2020 · 6 comments
Closed

Add option to don't drop comments #221

timocov opened this issue Jul 4, 2020 · 6 comments

Comments

@timocov
Copy link

timocov commented Jul 4, 2020

Related to #218 and #220.

Tools like uglifyjs or terser may rely on some comments like /*@__PURE__*/ (see side_effects on https://github.com/terser/terser/blob/504b9677d2d6086025ead5afb713e151877944b2/README.md#compress-options).

In some projects you can't use TypeScript in transpileOnly mode (or don't want because you have already compiled code and just want to process JS files itself). The TypeScript leaves a comment like /** @class */ right before class' IIFE, which could be replaced (somehow) with /*@__PURE__*/ so terser/uglifyjs can understand it and do its magic with them (see mishoo/UglifyJS#2279).

It seems that esbuild drop all comments (licences as well) which does all comments-dependent processing unreal (dropping licences is the issue as well).

@evanw
Copy link
Owner

evanw commented Jul 4, 2020

The esbuild parser was designed for speed. It's not designed to be a code formatter. It will likely be extremely difficult to modify esbuild to ensure that all comments are preserved and in their original locations, especially as code can be moved around due to syntax transformations. I don't think esbuild is the right tool if you need to do this, and I am not planning on adding general comment preservation to esbuild. You will want to use other tools to do this instead.

I can see adding a special case for statement-level comments only. I believe I should be able to guarantee that those are preserved without rewriting the parser. That should be sufficient to cover license comments I think.

@timocov
Copy link
Author

timocov commented Jul 4, 2020

I can see adding a special case for statement-level comments only.

Is that comments "attached" to a nodes? I mean a comments right before a node something like it's in TypeScript AST). If so, I think it might cover cases with "class" comment as well.

@evanw
Copy link
Owner

evanw commented Jul 4, 2020

Is that comments "attached" to a nodes?

Attaching comments to nodes makes it easy for them to be accidentally lost. Instead I'm planning on creating a new kind of statement AST node for statement-level comments.

@evanw
Copy link
Owner

evanw commented Jul 5, 2020

Relevant to this issue: I'm currently adding limited support for __PURE__ comments in esbuild (interpreting them, not passing them through). It's being done as part of some ongoing work for tree shaking. See #86 (comment) for context.

@evanw
Copy link
Owner

evanw commented Jul 6, 2020

I just published a release with support for __PURE__ comments. I also added pass-through printing of them when minification is disabled.

Edit: Note that this is only for __PURE__ comments that esbuild recognizes, which are only those that become attached to CallExpressions and NewExpressions. Like I said above esbuild wasn't designed for general-purpose comment preservation.

@evanw evanw closed this as completed in d7679fc Jul 6, 2020
@evanw
Copy link
Owner

evanw commented Jul 6, 2020

I closed this because both __PURE__ comments and license comments have been implemented. I believe that should be sufficient for your use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants