Andarist / react-textarea-autosize

<textarea /> component for React which grows with content

Home Page:http://andarist.github.io/react-textarea-autosize/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

package.json duplicate browser exports

mkilpatrick opened this issue · comments

"browser" is defined at both the root and in exports which can cause issues in some bundlers. Specifically, this is an issue using Vite/Rollup in SSR mode and defining a worker condition. I'm not sure if this is specifically a Vite issue so I opened an issue with them, but either way it'd be more correct to clean up the browser field in this package. See the warning below.

https://publint.dev/react-textarea-autosize@8.5.2

I'm pretty sure that this is Vite bug. We need package.json#browser to support older browsers (like webpack 4 that is still widely used).

What it's happening is the worker+module condition gets resolved (./dist/react-textarea-autosize.esm.js) and then the browser field maps that to ./dist/react-textarea-autosize.browser.esm.js.

There's a long thread in solid: solidjs/solid-start#263
In summary, this behavior has been there for a while and webpack and rollup (plugin-node-resolve) does the same thing (https://github.com/patdx/package-exports-test). Changing this will misalign with other bundlers and might break some packages.

I think browser field should be ignored when exports field exists but I'm not sure how we can solve this problem in a nice way.

I think browser field should be ignored when exports field exists but I'm not sure how we can solve this problem in a nice way.

This isn't how it should work (I was surprised about it when I discovered it). See the thread here: https://twitter.com/AndaristRake/status/1622675620026101760 . So you are right - this would break things and we don't want that.

After a second thought - I actually might have broken it in: https://github.com/Andarist/react-textarea-autosize/pull/373/files#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519R22 . Previously we had a specific file for the worker condition - it was just a copy of the one targeting node so the content was the same but the filename was different. This got deduplicated in this commit but that broke this.

Sorry for the confusion and thank you for the investigation! I'll see what I can do about this.