Expose react/lib/* for plugins

[mjackson]

It's currently difficult (impossible?) to create plugins for React that use any of the stuff in lib without using crazy hacks.

What's the best way to do this? Separate modules?

[pieterv]

Very much agree with this issue, the only way we (react-bootstrap project) have been able to support both amd/bower and cjs/npm environments whilst using stuff in lib's is by copying the react files into our project.

[sophiebits]

Can everyone who's interested in this list the specific modules/functions you're interested in? We intentionally ship a small public API so that we can feel free to make internal changes.

[mjackson]

I guess the main ones I'm using right now are ExecutionEnvironment and ReactUpdates. I also use invariant and warning, but those would be pretty trivial to implement myself.

[pieterv]

cloneWithProps is the big one for us, react/addons is a nightmare to configure across amd/bower and cjs/npm so not really an option.

We also use EventListener, cx, ReactTransitionEvents, invariant, merge but could understand the need to keep some of them private.

[sophiebits]

cx is public as React.addons.classSet so that falls into almost the same category as cloneWithProps. What are you using EventListener for?

[pieterv]

We use EventListener to bind to global events with IE8 support.

[sophiebits]

Okay, going to count that feature request as a vote for #285.

[pieterv]

Yes #285 would be prefect for what we are doing!

Also merge will no longer be needed if we can rely on Object.assign.

[davidaurelio]

+1
I’d like to have access to ReactTransitionEvents.

[sophiebits]

It's unlikely we'll ever expose ReactTransitionEvents as a public API as it's just a thin wrapper around browser events and is used only in ReactCSSTransitionGroup, not more widely. (Essentially, we don't want to commit to supporting that module.)

[davidaurelio]

That makes perfect sense, of course. It just seems so unnecessary to duplicate functionality like that when it’s “already there”.

[syranide]

#2251 (comment)

[mjackson]

It's clear now that if you're using internals, you're using them at your own risk. Going to close this for now. If anyone knows a specific internal they'd like to expose, please follow up in a separate issue.