Use rescript.json dir as working dir for js-post-build #8195
+21
−8
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
The
js-post-buildcommand's working directory was unpredictable in monorepo setups. The command would run in whatever directory the build process was invoked from, which could vary depending on whether you're building a specific package or the entire monorepo from the root.This made it difficult to write reliable post-build scripts that depend on relative paths or need to access files relative to the package.
Solution
The
js-post-buildcommand now always runs in the directory containing therescript.jsonwhere it is defined. This provides predictable, consistent behavior:js-post-buildin its ownrescript.json, the command runs in that package's directoryrescript.json, it runs in the root directoryThe absolute path to the compiled JS file is still passed as an argument, so scripts can reference the output file unambiguously.
Example
Previously,
./scripts/process.shwould fail if the build was run frommonorepo/. Now it reliably resolves relative topackages/my-app/.Breaking Change
This is a breaking change for users who relied on the previous behavior where the working directory matched the build invocation directory. However, the new behavior is more predictable and aligns with how other per-package configuration options work.