Rollup warnings

[vovsemenv]

Provide a general summary of the issue here

when i build with vite@5.4.0 i get this warnings

"/*#__PURE__*/"

in "node_modules/react-aria-components/dist/Breadcrumbs.mjs" contains an annotation that Rollup cannot interpret due to the position of the comment. The comment will be removed to avoid issues.
node_modules/react-aria-components/dist/ComboBox.mjs (49:42): A comment

"/*#__PURE__*/"

in "node_modules/react-aria-components/dist/ComboBox.mjs" contains an annotation that Rollup cannot interpret due to the position of the comment. The comment will be removed to avoid issues.

🤔 Expected Behavior?

no warnings

😯 Current Behavior

warnings

💁 Possible Solution

No response

🔦 Context

No response

🖥️ Steps to Reproduce

-

Version

1.3.1

What browsers are you seeing the problem on?

Other

If other, please specify.

No response

What operating system are you using?

macos

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

[snowystinger]

Sounds like a rollup or vite issue? have you checked their repos for that error or any bugs around it?

Otherwise, we'd need to know more about why it's thinking that it's invalid https://rollupjs.org/configuration-options/#pure but nothing is jumping out at me, other than I'm not actually sure what is generating the annotation. That's just a provider from a createContext call, so possibly React is generating it. Could check React and babel's docs to see if they have any bugs as well.

For reference, this the file and the Pure annotation is on line 49 https://www.unpkg.com/browse/react-aria-components@1.3.3/dist/ComboBox.mjs

[synecdokey]

Something jumping out to me is the fact that examples show the comment placed before a statement, not in the middle of it like the ComboBox generated code.

[hosenur]

Any fix for this ?

[snowystinger]

Not yet, someone will need to figure out if the PURE annotation is actually a bug in rollup or if it's a bug in our transpiled code first.

[matt-aaron]

The createElement function is what should be marked with the /*#__PURE__*/ annotation. It appears the annotation is being misplaced due to the transform of the nullish coalescing operator.

I was able to recreate the issue in a simplified Parcel REPL.

While the solution appears to depend on one of the upstream libraries, doing either of these things seems to fix the issue:

• Ditch the nullish coalescing operator
• Using an explicit return instead of implicit in the arrow operator

[snowystinger]

Thanks for providing the reproduction, we'll definitely want to get that fixed. I've opened the bug in Parcel as well https://github.com/parcel-bundler/parcel/issues/9947

In the meantime, patching such as patch-package should be able to help users work around the problem.