'publishConfig' not working as expected?

[TimRoe]

Not sure if this is a bug so created this Q&A to validate my understanding is in alignment with expected behavior around publishConfig package properties since, if so, I think there's a bug.

In searching I did see this bug report that sounds similar but not precisely matching. I also came across a pnpm bug more closely aligning to my observed behavior, but my project is using yarn--was on 3.6.1, same behavior updating to 4.0.2.

My project setup is a yarn workspace containing multiple packages. One package is a set of design system components that both has the ability to be run locally (Storybook to play with components via React Native Expo) and is a published package capable of being consumed by other React Native apps (including non-Expo apps so expo can not be a package dependency). Currently, we are separating these flows with a file that leverages try-catch functionality based on file existence and the App.tsx for the local running is in .npmignore so the published package try fails to get App.tsx and catches another file to just have the components. It works, but it's ugly.

So, upon noticing the publishConfig having a main file that overrides the main file when in a published tarball, I thought I could rework this flow to simplify and have the package.json contain:

{
  "main": "src/App.tsx",
  "publishConfig": {
    "main": "src/index.tsx"
  },
}

and when published App.tsx would continue being ignored by the presence in the .npmignore file while the index.tsx containing components would be present and we could get rid of the ugly try-catch workaround, meaningfully simplifying our code. However, the published package with this configuration contains App.tsx because it's the main file (overrides .npmignore) even though it should not be when published due to publishConfig.main. So then within a consuming app, it errors on initialization because App.tsx is present and contains dependencies not present in those apps (even if the code will never be hit).

So, is this a correct interpretation of how publishConfig should work? That the packages original main file should no longer be considered relevant and be able to be NPM ignored since index.tsx is the main file for the published tarball? Or is there a reason that the published tarball needs to maintain the original main file even though it should not be relevant with the publishConfig override?

If this is anomalous behavior, is the bug linked above (#5641) the correct issue to follow for resolution or is this a separate bug?

Thank you for clarification!