Moving bsconfig to package.json

#1

Hey, besides aligning more closely to how projects in Js land are being maintained, this would bring parity between reason package names and js package names. and if done properly, we will be able to remove the need to specifically add BS packages. which is nice for developer ergonomics.

#2

I thought about this but I had an impression that package.json could be very large, another thing is that it’s not obvious if a project is a bucklescript project or not without bsconfig.json place holder

#3

Wouldn’t the ‘.res/.re’ files and “re/bsconfig” property in the package.json make it easy enough to tell that it’s a ReScript/Reason project?

Also, I personally would rather have a single project dependency, etc. config file (even if it was on the larger side).

I also wonder if it was possible to not have to define “bs/redependencies” and just automatically use what’s in the package.json dep. list… how would that help with making the barrier to entry lower for new ReScripters?

#4

I would maybe suggest a third approach.

The only thing bugging me with the bsconfig is that you have to have your dependencies in two places (package.json and bsconfig). It would be a huge step forward if this could be changed so that they only live in the package.json.

For the rest of bsconfig you could maybe go with a similar approach to for example Jest and have multiple places where the config could live. Either in package.json or in a separate file.

#5

@bobzhang package.json could be large, but some people(myself included) prefer a single place to look at and dont care about size. It’s a very common thing in JS community adopted by almost all common tools(Jest/Eslint/Prettier etc etc) to do something like:

  • You can write your config in package.json(most people do)
  • If your config becomes complex, just say in package.json that you configure that lib in some file.

e.g
adding a section in package.json called rescript. which can either contain what’s bsconfig currently. or, a field called: "externalConfig: that points to a file where bsconfig is.

Not having to repeat the package name + rescript packages is a huge win for developer ergonomics

#6

To keep backwards comp easy, we could check for package.json and keep checking for bsconfig(although, would be great to see how we can remove the need to re-specify rescript packages) and add a warning asking people to move. package.json will be taken if present else it’ll fallback to bsconfig

#7

Just noting here that TypeScript has tsconfig.json, which seems to be working for them. At least people coming to ReScript from there wouldn’t find bsconfig.json something totally unexpected.

#8

@yawaramin good point.
So maybe we can align on that, (maybe change to rsconfig.json?)

But if we align to TS, we should still be removing the double indication of what packages are reason packages(e.g the presence of the file is indication enough).
And we should not specify package name there either.

E.g rsconfig.json should be reserved(like ts) to compiler options, not package management, that’s the responsibility of package.json.

#9

I think that would be difficult. BuckleScript right now, if I remember correctly, doesn’t even need to look at the package.json. It reads everything it needs from bsconfig.json. If it did have to read, parse, and validate package.json, first of all that would (of course) add some latency to every bsb call, and also how would it know from looking at the package dependencies which ones are BuckleScript dependencies? Would it walk the node_modules directory structure for all the packages trying to find .ml/.re/.res files and mark those as BuckleScript packages as deps? What if those files are coincidental and the package is not actually supposed to be a BuckleScript dep?

#10

Hmm, if we go with the latest iteration(e.g package.json for package management, deps+name in rescript case) - it will only need to parse/look at package.json for -build-world. for everything else(e.g each bsb run) it will keep looking at bsconfig(rsconfig?). for deciding which packages are rescript, it could just use the same logic typescript uses. e.g look for the bsconfig/rsconfig.

#11

I.e. for -make-world it will need to traverse the node_modules tree to figure out all the BuckleScript packages.

Keeping in mind also that the templates that ship with BuckleScript today all set up to run -make-world continuously in watch mode, of course that can be changed. But users will also need to be educated and reminded to separately use -make-world when they change any deps.

#12

@BlueHotDog I suggest creating an issue with your proposal in the rescript repo.

#13

done


hopefully didnt forget much.

#14

I would suggest a half-measure:

For me, it would be enough to add a bsb command for adding/removing packages without having to do it in two places. E. g., npx bsb install bs-service-worker would install bs-service-worker locally and add it to the bsconfig package dependencies.

(Not that I have any objections to just using package.json–I would just suggest this if that doesn’t work out.)