Support rescript.json

[cometkim]

Resolves #5278

• Introduce a new compiler flag -p which means "project". The location of the rescript.json (or bsconfig.json) file allows user to specify the project path where the build/format/etc will start.
  Don't introduce any new flags. This will be discussed separately if needed.
• The binary determines wether to use rescript.json or bsconfig.json. rescript.json precedence over bsconfig.json.
• When walking dependencies, rescript.json is tried first. Ignores bsconfig.json if present.

[cristianoc]

Quick Q: what's the rationale to rename the concept of config to manifest?

[cometkim]

Quick Q: what's the rationale to rename the concept of config to manifest?

It doesn't rename config to manifest, it's a separate concept the part dealing with user manifest as data.

manifest logic is cheap and can be shared across multiple modules. config logic is heavy and can be derived from manifest and system state.

[cristianoc]

Quick Q: what's the rationale to rename the concept of config to manifest?

It doesn't rename config to manifest, it's a separate concept the part dealing with user manifest as data.

manifest logic is cheap and can be shared across multiple modules. config logic is heavy and can be derived from manifest and system state.

Not sure I understand the answer -- but sounds like you've thought about it, so I might ask more later on during review.

[cometkim]

I'm cleaning up the heavy logic of config. It's not pure and hard to compose because it uses a lot of system calls while parsing the configuration simultaneously.

I extract the pure part (almost json parsing) from there and give it the name manifest.
So the flow would be json -> manifest -> bsb_config.

bsb_config is for bsb, but the manifest can be easily shared by other modules like syntax, gentype, etc.

---

This is not a good time to review because I haven't removed the redundant logic in bsb_config yet.

[fhammerschmidt]

What's the status of this? Would love to have this merged so that I can implement support for it in rewatch as well.

Furthermore, rescript.json should be an opportunity to clean up the config.

Personally, I would remove the following elements:

• reason
• entries
• pp-flags (think those would only work ml files?)

Also, I would rename the remaining fields that contain "bs":

• bs-dependencies --> dependencies
• bs-dev-dependencies --> dev-dependencies
• bsc-flags --> compiler-flags
• bs-external-includes --> external-includes (or remove that as well)

And the source item has a lot of attributes that are experiments or even don't work at all (e.g. resources, group)

[cometkim]

Furthermore, rescript.json should be an opportunity to clean up the config.

I think so. also as you mentioned, each field setting has too many variants so I want to clean this up too.

The goal of this PR is to support all existing fields for now. Others will be follow-ups.

The refactoring to separate config and manifest should make it easier and to use manifest parsing for third-party tools as well.

---

I've taken a break from OSS work in recent months. Will revisit soon, hopefully in this month.

[fhammerschmidt]

Ah yes. In fact even the current state of this PR could be split up into multiple.

1. support for rescript.json just the file with the same contents + deprecation warning for bsconfig
2. the missing fields (gentype, ...)
3. the split of the config into manifest and config

No 1. should be relatively straightforward?

[cometkim]

No 1. should be relatively straightforward?

Yes, I can make it since I remember the steps for. I'll make a clean PR for it this weekend.

[DZakh]

I've just thought that it would be nice to automatically convert bsconfig.json to rescript.json when user runs a compiler and it detects bsconfig.json.