Rename react/lib/* to react/private/*

[gaearon]

As suggested on Twitter.
Let’s do it so we don’t get more broken components?

[zpao]

I still like the lib/ pattern 😢 It might be slightly more obvious to people not to require files from private/ but nothing really stopping them and we'd end up telling people the same thing - "don't require things from here".

[gaearon]

While we have been telling this to people, the reality is that a lot of people (me included) thought it was relatively safe some time during 0.12, and there is a bunch of components whose authors don't know this needs changing.

Renaming it for 16 would serve as a good warning for any existing components, as it would effectively force authors to explicitly opt into using "private" parts or find workarounds.

[zpao]

We could go all in and really obfuscate it. Some hash or something that gets added to our build pipeline and changes for every major release.

echo '16' | md5
5b6b41ed9b343fed9cd05a66d36650f0

[jimfb]

👍 :%s/major release/build/g

[zpao]

Nah, shouldn't do it on every build. I thought about it but that would probably screw our own packages so we need some reliability (eg react-dom 15.0.0 should be able to use react 15.0.1).

[jimfb]

Our own packages should have a way of accessing the internals needed, using private API like SECRET_DOM, without indexing into lib. That has the added bonus of allowing addons to be put into separate UMD builds.

[iamdustan]

while there isn’t a defined, documented API for accessing internals to create a renderer, this change will greatly hinder all the experimentation taking place in the custom react renderers community. While that is a known experimental use case where things will break (I believe maintainers and users of these renderers understand this), removing that capability or hiding it in a system like md5 hash names would be detrimental in my view.

[jimfb]

I feel like people experimenting should check out the React repository anyway, rather than relying on an NPM build. Maybe I'm wrong, curious what @gaearon thinks about that point.

[zpao]

Depending on how we did it, I don't think it would really hinder experimentation. You would just be forced into knowingly using non-public APIs and if we went down that hash per major route, you'd just have to update paths for a major version. We'll definitely keep the use case in mind though. And you're paying attention so I'm sure you'll chime in (or I'll reach out) if we make any drastic changes that would be unrecoverable.

[gaearon]

I feel like people experimenting should check out the React repository anyway, rather than relying on an NPM build.

Building it and then doing something like npm link can be a pain considering you’d want the renderer to be a peer dep, and to both run tests in it and experiment on some project in another directory. This is when symlinks get too inconvenient. I definitely see the appeal of just using the npm package when fiddling with the renderers.

Depending on how we did it, I don't think it would really hinder experimentation. You would just be forced into knowingly using non-public APIs and if we went down that hash per major route, you'd just have to update paths for a major version.

Something like react/lib/5b6b4/* (5 chars would be enough IMO) wouldn’t be too bad if we communicated clearly what this is. We could ship a react/lib/README.md that explains that the hash changes on every major version.

[iamdustan]

I’ve thought about this a bit more over the weekend and am currently opposed to this. The reasoning against this is:

1. It feels like a kneejerk reaction to a community problem. While it is a valid solution (with a precedent by babel doing something similar), I suspect that community pressure and education will be enough to prevent or decrease the impact of this behavior happening as time progresses.
2. It breaks conventions and makes a certain class of valid use cases more difficult. As mentioned, it even requires thought and additional work for your own OSS products with RN
3. It’s a bit of a hack to implement truly private modules. And even with that it isn’t fully private because maintainers could look at the docs for how the hash is generated and still require private internals. Ideally, if we want to add a truly private concept to the module system, it should be built in to npm and/or node require itself.

[blainekasten]

An API that could satisfy everyones needs:

const reactLibHash = require('react/libHash'); // e.g., "M0D3F"
const libIWanted = require(`react/lib/${reactLibHash}/ThingIWant`);

This would let you use the hashing method, while still allowing people to get the things they want from libs. But making it awkward enough that it should hopefully be only used when actively sought after. Not documenting it could help with that.

Downsides are that it doesn't work with the import system as you can't interpolate variables into the import path.

Ultimately, I agree with @iamdustan on every point. It seems like a user problem more than your teams problem. If somebody wants to depend on an internal item and it gets removed in the next version, then it's up to them to handle that situation over you guys. That's an OSS-wide issue, not just a react issue.

[toxicFork]

Agree completely with @iamdustan as a custom renderer author. Currently it is necessary for my project to use react internals and I am aware that it may break even with patches or minor updates to react but that's something I can handle for now. Having build specific hashes would just make it a bad experience for almost everyone.

Naming it "private" instead of "lib" will make it more apparent that things may break so that's good enough in my opinion.

To solve the real problem at least in my case is to find out why the third parties are trying to use private parts of react.

To be even more specific, I am seeing great progress towards separation of DOM and react, and for react three renderer, with every update, fewer private react parts need to be used.

Eventually when react dom is completely separated we will be able to look at it and see how it works as an independent entity and if it does not touch react private parts then it will be very comfortable for other custom renderers to appear and be more stable.

I am guessing that eventually the same may happen to the other popular private parts, I guess they may need to be exposed in the stable api or modularized. Or third parties could be poked. Poke us but don't punish us :)