Stop committing generated JS files

[agarwal]

We've had some discussion about this and apparently there is some argument for committing the JS files generated by ReScript. I'm not yet convinced. Let's review this decision.

After some experience following Patrick Ecker's preference, I haven't seen much benefit. We should document an additional step in the manual regression testing guide after removing the generated JS.

When testing the site after a ReScript version upgrade, we should capture the generated JS before and after the upgrade and inspect the diff. Since the JS module systems keep changing every few months and ReScript development team may not always think about the impact of their changes in generated code, we have to be suspicious/defensive about any changes in generated code.

• Also, we can remove the .gitattributes file when this happens.

[agarwal]

When testing the site after a ReScript version upgrade, we should capture the generated JS before and after the upgrade and inspect the diff. Since the JS module systems keep changing every few months and ReScript development team may not always think about the impact of their changes in generated code, we have to be suspicious/defensive about any changes in generated code.

Maybe... but we trust the ReScript compiler, right. Inspecting its output seems unnecessary and out of scope.

[agarwal]

• Also, we can remove the .gitattributes file when this happens.

Done in #156 (86634b0).

[agarwal]

@kanishka-work In the interest of faster iteration, I merged PR #156 immediately. However, please QA and I can create an additional PR to address any comments you may have. Note I also created a new QA column in our project board.

When testing the site after a ReScript version upgrade, we should capture the generated JS before and after the upgrade and inspect the diff. Since the JS module systems keep changing every few months and ReScript development team may not always think about the impact of their changes in generated code, we have to be suspicious/defensive about any changes in generated code.

Maybe... but we trust the ReScript compiler, right. Inspecting its output seems unnecessary and out of scope.

I don't trust new releases of the ReScript compiler currently. The following thread demonstrates one problem in a recent release:

https://forum.rescript-lang.org/t/ann-rescript-9-0-1-is-released-bug-fix-release/1099/5

Testing a new ReScript release will probably surface any impact on our codebase, but until the ReScript team has a few major releases where people don't report issues after the release, I don't see a compelling reason to trust their automated test suite. Alternatively, we can use a policy of not taking new major versions for a while which you have noted in other contexts.

[agarwal]

I don't trust new releases of the ReScript compiler currently.

Ok, got it. Yes, I guess their updates are not fully reliable. I am also in favor of always being a little behind the latest version. I wouldn't upgrade to a new major version for at least a few months till after it is released. By then hopefully they've had some more minor releases to tease out problems.

I marked this as done. I created a note in the "Ecosystem Release Notes" wiki page regarding being conservative with ReScript upgrades. I didn't close the issue in case you have anything else in mind.

[agarwal]

I still need to do the following, so moving back to In progress.

• Remove postinstall script, as requested at Don't commit generated JS files #156 (comment).

Note I also created a new QA column in our project board.

Let's call the column "maintainability review" or more concise version of that concept? I want a strong emphasis on the person creating the PR to do the QA and self review before switching the PR from draft to "ready for review"

I want the PR reviewer to play the role of representing the rest of the team and deciding whether the changes will hurt readability or maintainability.

[agarwal]

Remove postinstall script

Done in #208.