This looks good so far. Let's keep it open until the whole V4 ppx is finalised.

Side comment: I verified that V4 & Jsx don't break my test project having dependencies of V3 modules. So, I tried to run the battle-test of V10 & V4 & Jsx on my company projects. I encountered some errors before verifying that V4 & classic, V4 & Jsx will not break the backward compatibility. I'll leave the issue in the compiler.

Side comment: I verified that V4 & Jsx don't break my test project having dependencies of V3 modules. So, I tried to run the battle-test of V10 & V4 & Jsx on my company projects. I encountered some errors before verifying that V4 & classic, V4 & Jsx will not break the backward compatibility. I'll leave the issue in the compiler.

Can you expand a bit on this?
Did you find some problem, and will document that in a new issue?
Or were no problems found?

Side comment: I verified that V4 & Jsx don't break my test project having dependencies of V3 modules. So, I tried to run the battle-test of V10 & V4 & Jsx on my company projects. I encountered some errors before verifying that V4 & classic, V4 & Jsx will not break the backward compatibility. I'll leave the issue in the compiler.

Can you expand a bit on this? Did you find some problem, and will document that in a new issue? Or were no problems found?

I ran V10 & V4 & Jsx on my test project which is a small RescriptReact app. It has dependencies of the RescriptReact module I made with V3 bsconfig. I've tested the scenarios (V3, V4 & classic, V4 & Jsx), and they worked fine.

But I ran V10 compiler in V3 mode on large applications(company projects), it throws several errors. I guess it is not related to V4 or Jsx. So I left the issue in the compilerrescript-lang/rescript#5493

Let me know if anything I can help on that.

I totally agree on the comment from@ryyppyrescript-lang/rescript#5484 (comment) Here is my thought for the future plan. What do you think?

1. RemoveJsx from rescript-react.
   If the namespaceJsx is occupied here in rescript-react, there will be a problem(in future graceful migrations) when we addJsx in the compiler.Jsx should be containing the primitive types, functions, modules which are vendors for the 3rd party modules, such as rescript-react, or rescript-solidjs, etc.

2. Add the new jsx APIs inReact.res andReactDOM.res
   If the upgrade plan is that V4 & the new jsx transform will be shipped with upgrading rescript-react, then we don't need to add a new module here. It is enough to add the new jsx transform React APIs intoReact.res andReactDOM.res Those APIs are just for the React anyway.

3. AddJsx in the compiler and bind the types to rescript-react
   The initial version ofJsx can be added to the compiler for the experimental feature. Then we can bind the rescript-react toJsx. For example,

// React.restypeelement=Jsx.element// ReactDOM.res@module("react/jsx-runtime")externaljsxKeyed: (string,JsxDOM.domProps,string)=>Jsx.element="jsx"// Jsx in the compiler

Does it make sense to you?

The breaking change is introduced by mergingRescriptReact.res intoReact.res.

Side comment: I realized why some of react component binding was not written with@react.component. Simply it is not possible, because the ppx will transform@react.componet usingReact.res itself. 🥲 Therefore, I write the binding without@react.component, but it is compatible with ppx V4.

How does one test this?
Perhaps one way is to create a separate sample project, which installs the compiler from master, and the rescript-react from this PR, and tests the various things that have changed?

How does one test this? Perhaps one way is to create a separate sample project, which installs the compiler from master, and the rescript-react from this PR, and tests the various things that have changed?

Yes exactly. That is how I develop and test in my local env.

How does one test this? Perhaps one way is to create a separate sample project, which installs the compiler from master, and the rescript-react from this PR, and tests the various things that have changed?

Yes exactly. That is how I develop and test in my local env.

Great! Would you create such a project?
That would also be the base example to ask people for feedback.
As it will take a while before both are published in a way that people can try.

How does one test this? Perhaps one way is to create a separate sample project, which installs the compiler from master, and the rescript-react from this PR, and tests the various things that have changed?

Yes exactly. That is how I develop and test in my local env.

Great! Would you create such a project? That would also be the base example to ask people for feedback. As it will take a while before both are published in a way that people can try.

Sure! I'll work on it.

Wow! it works! 👍

• compiler v10.1
• rescript-react v0.11
• jsx: {version: 3, v3-dependencies: [rescript-relay]}
• bs-flags: ["-open ReactV3"]

Still a bit confusing.
It's mainly intended to work when the main project is built with v4.
If the main project is built with v3, it's kind of expected that normal dependencies work out of the box. And they would, if one did not install latest rescript-react.
Thinking...
Perhaps if the main project is build with v3, then there's simply no reason to install latest rescript-react.

At least we don't need to separate the rescript-react version per compiler and jsx version.

(Before)

• rescript-react>=0.11.0 for compiler v10.1 + JSX v4
• rescript-react<0.11.0 for compiler v10.1 + JSX v3

(After)

• rescript-react>=0.11.0 for compiler v10.1 + JSX v4 or JSX v3

It's mainly intended to work when the main project is built with v4.

If the main project is with v4, then dependencies are impossible with v3 by all means.

The option of propagating and v3-dependecies are for the cases, I think
1. dependency is written without@react.component or v3 based. e.g. object props
2. user want to upgrade the compiler v10.1, but have to keep using v3. e.g. async/await
No reason to install the latest rescript-react

It's mainly intended to work when the main project is built with v4.

If the main project is with v4, then dependencies are impossible with v3 by all means.

Not beautiful, but it's possible to switch to V3 inside a V4 project, and use a V3 dependency.
I think there are enough escape hatches to cover corner cases, just in case.
Next up, document the upgrade process better. But to do that it would be nice to have some real upgrade experience, so one can direct the docs to issues that do arise in practice.

Perhaps the way to go is to cover the functionality in the upgrade docs, then do another round of feedback.
Based on responses, one could make updates to the mechanism, or to the docs describing it.

Not perfect, but the v3 and v4 apps can use the same latest rescript-react with options you've made. I think this backward compatibility of rescript-react would be a benefit for many users.

Anything to clean up here?
Functionality-wise it seems complete now.

It's like done now.
As I addedbf2f897,legacy directory could be removed once most users are not using v3 anymore.

@mattdamon108 any more feedback, anything to change in this PR before merging?
Next up, publish to npm as@rescript/react@next.

@mattdamon108 any more feedback, anything to change in this PR before merging? Next up, publish to npm as@rescript/react@next.

No, it's done.

@mattdamon108 would you take a look at the checked in.bs.js files? Is everything in them necessary?