Bug: circular import between shared/ReactSharedInternals.js and react/src/React.js about react

[markerikson]

I'm a bit confused on the overall context. Are you trying to put together some kind of custom build setup that is separate than the existing React package build pipeline? If so, why?

[bpstrngr]

Yes, well I'm not using npm, but building dependencies from source so that I can have the ability to maintain/customize them instead of patching arbitrary build outputs. Not necessarily React in particular, but being able to build them is my bare minimum for any dependency.
Either way I did try to rely on the existing pipeline configs, but they're (expectably) rather complicated (eg. haven't spotted where package cross-specifiers are replaced in imports, esp. since devDependencies are rarely split in package.json) and documentations don't extend beyond a user perspective of "npm install react react-dom". It was easier to figure out from looking at the source files, where I noticed this particular circular import and the multiple default exports in "shared" package which prevent bundling eg. "react" and "react-dom" (etc.) separately (either you bundle them all together, or you re-include "shared" modules in each, neither of which seem possible without redirecting from shared/ReactSharedInternals' un-treeshakable circular namespace import of "react" to react/src/ReactSharedInternals directly).
The question is simply whether the "shared" package is intended to be modular despite its multiple peripheral defaultexports, and even if not,
how does the official build pipeline resolve this seemingly even unnecessary circular import (import("react") -> shared -> react -> shared -> ⛔ can't access react/src/sharedinternals on react before exported by it) for the distributed packages?
If neither is known, then I'll just continue with my redirect workaround and "shared" redundancies.

[markerikson]

I don't have a specific answer here, but I agree that the React build pipeline is incredibly complicated. Given that, my own advice would be to rely on some modification of that existing pipeline as a running fork, and not try to create your own.

(I've done this myself while working on adding sourcemaps the React pipeline, as well as a long-running fork of the React DevTools.)

What actual build changes or lib changes are you trying to accomplish?

[bpstrngr]

that's alright, thank you!
2 of them:

• no redundancy of "shared" modules if I want to bundle eg. "react" and "react-dom" (etc) separately, by "shared" being a truly modular package or else split into modules of its defaultexports. the redundancy is not huge, but hard to tell the overlap/difference.
• much more simply why is ReactSharedInternals located in "react" if it is re-exposed from "shared" to other packages (if they use it, and not just there to have a cycle in "react" for kicks because peers actually access react/src/sharedinternals directly), and "react" already imports from it just as well (or worse, because this particular cycle breaks bundling by the source design).

[markerikson]

Heh, not quite what I was asking :) Those are "why is React's module and build setup designed this way?", which I can't really help with.

I'm asking why you're even trying to customize React's behavior at all - what customizations are you trying to do that led you to try to build React in the first place? And given that, why aren't you just using the existing build setup as-is?

(unless I'm misunderstanding and "React's shared internals" is related to the original reason why you're doing any of this at all?)

[bpstrngr]

I don't intend to change anything in React's functionality, just trying to gain control of its source, as part of becoming less dependent on and more conscious of npm's bottomless dependency graph of inaccessible build outputs. I expect this to be possible, and it was, I have the bundles, but it takes redundancies of "shared" "modules" and an edit to the circular import. So the question is about the architecture, and these 2 issues are indeed what I would change (the second already edited, the first takes more work to edit defaultexports and corresponding imports), unless there is an answer to the "why" that I'm unaware of, and can't piece together from the build configs.

[markerikson]

Honestly, I'm pretty confused at what you're trying to accomplish, then :)

React's build system works as-is.

• How is building it from source yourself "being less dependent on NPM"?
• How is writing your own build setup for React going to improve the situation?
• If you're concerned about installing React from NPM, why not download it once and vendor the pre-built artifacts?

Beyond that, given how complex React's internals are, and the way that the "shared" pieces actually get loaded and referenced in a page... I would be suspicious that a homegrown build setup of the same React source files would actually work correctly.

[bpstrngr]

• not using npm is arguably as independent from npm as it gets.
• writing my own build setup improves the situation of not being able to report on details of the current build pipeline (I successfully built with the total of ~3 simple edits above, plus flow-parser, astring and rollup without config. I'll see soon how it works to tell if you're right and there's more to it).
• that would not prove the replicability/maintainability of the build to the user (me).
  If the integrity of my current bundles will seem corrupt ( I just got to remix's react-router for a sufficient test) I'll see what I can do further, but beyond a complexity I'll certainly cave to leave React as a humanly irreproducible source architecture and therefore fork or favor alternatives. At this point I only had these 2 simple questions to it (ok the one about the "shared" package is not as simple). :)

[markerikson]

Yeah, I'll give up on this thread at this point.

I don't understand the point of trying to recreate a build pipeline that has been iterated on by dozens of engineers over 10+ years and is known to work correctly, especially when it's a build pipeline as complex as React's.

I can vaguely understand choosing to build React from scratch yourself just so you can verify the output matches the source, but I don't understand why you feel you need to write your own build pipeline in order to "prove" anything.

I strongly suspect the builds you're generating aren't going to work properly, and you're definitely not going to generate properly optimized production artifacts.

[bpstrngr]

that's alright, thanks for your thoughts so far. there are marginal benefits to having modular bundles: I can reuse parts of React in other contexts (eg. react-reconciler, which given these 2 issues can't be bundled without React itself and any other peer dependency). I only filed a bug report because the source by design has this circular import, which would be unnecessary, however the build resolves it. I can always be wrong too of course, eg. if the source is meant to only make a coherent whole together with that undoubtedly working build process. :) i'll close the issue if no one confirms this is unintended.

[github-actions]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[github-actions]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!