RFC: Improving the interaction between bsconfig.json & package.json

Development
1

Hi all,

I’m working on this PR to read the dependencies, devDependencies and name from package.json.

The related issue https://github.com/rescript-lang/rescript-compiler/issues/4621, https://github.com/rescript-lang/rescript-compiler/issues/5278

4 Likes
2

Here is an example of a monorepo https://github.com/aspeddro/rescript-monorepo-experiments/tree/monorepo-test-take-one.

The pinned-dependencies now are defined in package.json.

main-project bsconfig.json

{
  "sources": {
    "dir": "src",
    "subdirs": true
  }
}

package.json

{
  "name": "main-project",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@rescript/react": "^0.10.3",
    "dependency-project": "*"
  },
  "devDependencies": {
    "rescript": "^9.1.4"
  }
}
1 Like
3

Awesome! That’s a huge step forward for ReScript monorepo support <3

4

While I personally welcome simplified configuration, this change seems too invasive.

I would not want to be forced to use a package.json, considering there are emerging tools that do not even rely on the package.json/node_modules workflow.

Would it not be better to just have a separate rescript command that checks the dependencies and update bsconfig/rescriptconfig accordingly?

1 Like
5

I would not want to be forced to use a package.json, considering there are emerging tools that do not even rely on the package.json

I think within the JavaScript ecosystem there’s probably one concensus across all package managers and that’s the existence of a package.json file (since it’s also what any package repository requires). So I’d be hard pressed to think of a package manager that deviates (or expect one to do so in the future).

As for the node_modules workflow, I find it a better point of contention, though I don’t think it applies here.

As far as my understanding goes, the work being done here is mostly about how ReScript knows what modules it should look at to find ReScript code and which ones should be built.

There is an existing open compiler issue for support for things like yarn PnP (which no longer uses node_modules): https://github.com/rescript-lang/rescript-compiler/issues/3276 but I don’t think the changes being made here make that any more or less difficult.

6

In Deno, for instance, there is no necessity to publish a package with a package.json. For example: https://github.com/slectgit/qrust_bridge/

At the very least, I think it is preferable to keep the name, dependencies and devDependencies in bsconfig as well and make this change purely additive (i.e. only if the corresponding fields are not found in bsconfig, or something like that).

3 Likes
7

I just ran into the fact for ReScript that it doesn’t expose transitive dependencies. I believe this is a good thing, can we ensure this remains preserved in case we rely on package.json rather than bsconfig.json. (This also matches behaviour of newer initiatives like Plug 'n Play where you must define all the dependencies you use and can’t use dependencies of dependencies without declaring them)

To illustrate, say I have the following dependency chain A > B > C (A depends on B which in turn depends on C). C’s modules in this case are hidden from A.