fuse bsconfig into package.json

[aspeddro]

This PR is a proposal to read dependencies, dev dependencies and name from package.json

[aspeddro]

Need to resolve pinned dependencies. They are currently specified in bs-dependencies. Is workspaces in package.json equivalent?

[Minnozz]

Need to resolve pinned dependencies. They are currently specified in bs-dependencies. Is workspaces in package.json equivalent?

See this repository (note the branch) for a minimal example of workspaces: https://github.com/Minnozz/rescript-reproduce-issue/tree/pinned-dependencies-issue

[aspeddro]

Need to resolve pinned dependencies. They are currently specified in bs-dependencies. Is workspaces in package.json equivalent?

See this repository (note the branch) for a minimal example of workspaces: https://github.com/Minnozz/rescript-reproduce-issue/tree/pinned-dependencies-issue

thank you @Minnozz

An example of monorepo https://github.com/aspeddro/rescript-monorepo-experiments/tree/monorepo-test-take-one. The pinned-dependencies are defined in package.json

[cristianoc]

Could you explain the proposal at high level? This is still draft, so maybe in flow. But seems to introduce a breaking change to existing projects, while one would expect purely additive functionality.

[aspeddro]

Problem

• Currently dependencies and dev dependencies are added to package.json and bsconfig.json
• The name should be the same in bsconfig.json and package.json

This information is already in package.json.

Solution

Read package.json, iterate over the dependencies and devDependencies and check if a bsconfig.json exists.

This approach implies a loss of performance if the package.json is large, but I believe that people are willing to pay this cost in exchange for this ergonomics.

One caveat, I'm exploring the compiler, I might be breaking some rule.

Related: #5278

[aspeddro]

But seems to introduce a breaking change to existing projects, while one would expect purely additive functionality.

If I keep pinned-dependencies in bsconfig.json will it break for existing projects?

[cristianoc]

But seems to introduce a breaking change to existing projects, while one would expect purely additive functionality.

If I keep pinned-dependencies in bsconfig.json will it break for existing projects?

I guess the question is: is it true that any project correctly configured today will still work exactly the same after this change?

Also, I guess bsconfig allows to specify a subset of the dependencies defined in package.json. If so, is there still a way to do so. Should there be?

If one can do zero breaking changes, that's ideal. If some breaking changes are unavoidable, there's still the pending thing of using rescript.json, and one can consider to introduce the change at the same time as the rename.

[aspeddro]

I guess the question is: is it true that any project correctly configured today will still work exactly the same after this change?

No, after this change package.json is required.

One option to maintain compatibility is to keep name in bsconfig.json.

[cristianoc]

I guess the question is: is it true that any project correctly configured today will still work exactly the same after this change?

No, after this change package.json is required.

One option to maintain compatibility is to keep name in bsconfig.json.

Can you expand a bit on the explanation, even though it might seem obvious. And with a concrete example?

[aspeddro]

Sorry for delay.

Here an valid example build_tests/react-ppx that will fail.

• Compile search for package.json to read name field, but file is not found.

[cristianoc]

Sorry for delay.

Here an valid example build_tests/react-ppx that will fail.

• Compile search for package.json to read name field, but file is not found.

I suggest to turn this into a proposal with no breaking changes, give a description which is a bit more detailed than the one above (with examples) and try to reach consensus on the forum.