ReScript v12 js-post-build confusion

1

I’m trying to upgrade our massive production codebase to v12, so please expect several new topics :sweat_smile:

I just got this in the compiler terminal output:

The field ‘js-post-build’ found in the package config of ‘pace’ is not supported by ReScript 12’s new build system.

Yet, the docs still have it.

I really hope it’s not gone away because if it has, we will be stuck on v11 probably for ever :sob:

2

IIRC we haven’t said we aren’t going to have it. I just think it hasn’t been built yet for Rewatch.

3

Ah ok, that’s a relief. Thanks. The docs/blog read like the new build system is “done”.

I’ll try using the legacy build system for now.

4

See https://github.com/rescript-lang/rescript/blob/master/rewatch/CompilerConfigurationSpec.md#rescript-build-configuration

Most of it is there, could you give an example of what kind of command you are using right now?

5

Of course, this is our config in rescript.json:

"js-post-build": {
  "cmd": "./tools/gen.sh"
},

And the gen.sh file expects a single argument to be passed to it which is the path to the JS file that was generated by the rescript compiler. This is a relative path in the ReScript v11 build system. It’s impossible for me to know to what the path is relative – but if I had to guess, I’d say it’s relative to node_modules/rescript/. All I know is that it starts with ../../.

We use this script to compile a Flow types file from the @genType-generated TypeScript file. This is crucial for us to move forward with our rescript codebase without breaking important business features in our legacy flowtyped JS codebase.

6

I’ve run into a similar problem with that path resolution and try_package_path when testing ppx updates with relative paths in “ppx-flags”:

  "ppx-flags": ["../ppx"]

try_package_path: upward traversal did not find 'spice-ppx-test/../ppx' starting at...

I think it’s because it’s searching for spice-ppx-test, the name field from rescript.json, instead of the actual directory name?

I needed to use like "@greenlabs/ppx-spice": "workspace:../" in package.json so that @greenlabs/ppx-spice gets symlinked and use this instead in rescript.json.

  "ppx-flags": ["@greenlabs/ppx-spice/ppx"]
7

This has nothing to do with “ppx-flags”, “js-post-build” is simply not there.
Please create a GitHub issue for whatever problem you have with ppx-flag.

8

Hello @benadamstyles,

I’ve implemented the missing functionality in Initial implementation of js-post-build in rewatch by nojaf · Pull Request #8151 · rescript-lang/rescript · GitHub.

One twist: it would be easier for us if the ${file} argument were an absolute path. That makes more sense in a monorepo, since you might be building from the repo root or from a package.

This will behave differently from our old build system. That said, it’s something I think we’d change anyway for v13.

Would this block anyone? Most scripts can be adapted to handle absolute paths, but that would be on users.

3 Likes
9

absolute paths would be fine, in fact preferred! Thank you!!

1 Like
10

Great, you can try this out in v12.1
Let us know how it goes!

2 Likes
11

Works perfectly :ok_hand:

A few other things I had to contend with though:

  • Yes the path is now absolute but it points to the file under lib/bs, before I think it was relative to the project root.
  • The script you pass to cmd used to be run with a pwd that I think was node_modules/rescript, now it’s run with the expected pwd of the project root.
  • It totally swallows console/stdin streams. echo from the script or console.log() from child node processes are swallowed. I had to echo ... >> ./tmp.txt to do some logging.

These are not major issues but might trip people up and would be worth documenting if possible.

In general, MASSIVE THANKS for getting this done, it has allowed us to move fully back to the bleeding edge of ReScript and I hope to contribute bug reports and suggestions etc going forward.

1 Like
12

Thanks, this is useful feedback.

Yes the path is now absolute but it points to the file under lib/bs, before I think it was relative to the project root.

Yeah, the path under the project makes more sense.

  • The script you pass to cmd used to be run with a pwd that I think was node_modules/rescript, now it’s run with the expected pwd of the project root.

The pwd of the rescript execution makes most sense to me here.

  • It totally swallows console/stdin streams. echo from the script or console.log() from child node processes are swallowed. I had to echo ... >> ./tmp.txt to do some logging.

Good point, this is annoying, we should pipe the stdout/stderr to the current rescript process.

These points are worth revisiting in v13. Will take a look at this eventually.

Thanks for testing!

3 Likes