Improving the interaction between bsconfig & package.json

[BlueHotDog]

Hey, following up the discussion here: https://reasonml.chat/t/moving-bsconfig-to-package-json/2458/12 Opening this issue.

The problem

• Developers need, for every package they install, add it to package.json + add it to bsconfig, this is both confusing(isnt required in any other common tojs lang) and error-prone.
• Package name is required to match in bsconfig and package.json else weird errors happen

The theory

package.json should handle everything related to dependency management and packaging while bsconfig should handle compiler options(flags/errors/ppx etc).

The solution

• remove the dependencies from bsconfig
• remove name from bsconfig
• when rescript runs make-world it'll scan all node_modules, packages that include a bsconfig will be compiled.
• when rescript runs bsb, nothing changes

Bonus points

rename bsconfig to rsconfig?

[bobzhang]

There are some trade offs to be made. The benefit for removing bsconfig.json is stated above. The benefit for keeping it is that it is very easy to tell if it's a rescript project by inspecting whether bsconfig.json exists (like tsconfig.json). We need clear benefits to justify such big changes

[BlueHotDog]

Right, and i really would love us to follow typescript suite for everything related to developer ergonomics - Keep the bsconfig for BuckleScript configuration:

• warnings/jsx etc etc.
• Detecting if its a rescript project
• enabled ppxes etc

Stop doing anything else:

• What package is a dependency, this can easily be deducted from package.json(same way typescript is doing it) - This will reduce huge source of friction for newcomers(and old comers alike) - no one likes typing something twice and maintaining things in two places without some real benefit(to which i see very little if i'm not the linker developer)
• Remove package name - package.json is the de-facto source of truth regarding the name of the package.

Would appreciate re-opening the issue as your answer didn't really address the pain point

[pgbradbury]

There is a ticket in the Typescript project asking for the same functionality. It is very easy to see what language a project is using without that file in the root.

You also don't have to remove bsconfig.json, you can make it a hierarchy where it would look in package.json first, then for bsconfig.json for example. This is similar to what many javascript packages do it, allowing the development organisation the choice.

The clear benefit is centralising all configuration into one file, for example in my existing js project, I have all config for linting, testing, transpiling etc. all in one place.

[joakin]

package.json is a node.js specific feature, other platforms like deno, or tauri, do not use it. Having the compiler be tied to one platform and package manager seems like a bad decision thinking long term.

There is probably something in between like reading package.json dependencies if none are specified in rescript.json, or maybe add a flag to rescript.json with target/platform or something like that, and when that is node, rely on package.json and complain if the rescript.json has dependencies instead.