-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jaybell/remove-irrelevant-paths-from-tsconfig-in-hash #5587
Jaybell/remove-irrelevant-paths-from-tsconfig-in-hash #5587
Conversation
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/nrwl/nx-dev/FZhgCeWvUUamuKqDbEC5iQQ7N6b3 |
Nx Cloud ReportCI ran the following commands for commit b8e755b. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this branch Sent with 💌 from NxCloud. |
I love the idea! |
Thank you for the PR!
We can add a tasks runner option (e.g., selectively cache tsconfig) which is false by default but can be set to true in nx.json, and then we can do what you do with tsconfig.json. The hasher already takes options, so you can just use this option. I think for a lot of workspaces, the behavior in this PR is good, but for some it's broken. Does it make sense? |
Oh I did not know #1 was a thing! I am going to have to take a look at that. #2 was what prompted this PR since I figured the same logic could be applied to tsconfig.base.json I think having the option to enable/disable this PR in nx.json would be awesome, Would you like me to add that to this PR and then write some tests for it? Thanks for the feedback Victor! |
b56bfef
to
8dd8b43
Compare
Hey Victor, I went in and added that option for caching the tsconfig and updated the tests to test for that case. I had to expand the test cases a bit to be a bit more "realistic" so that I could calculate the ts alias and such so the tests are expecting more realistic hashes now for projects. Not sure where I should document that flag though. Let me know if you would like me to add it to the docs somewhere. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the late reply. I think overall it looks good. Left some minor feedback.
const fileHashes = fileNames.map((file) => { | ||
const hash = this.fileHasher.hashFile(file); | ||
return { file, hash }; | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why was hashGlobalConfig removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm that is a good question, I did this a while ago. I don't see a reason it should be so I will just add it back in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh actually, it was removed because of #1 the original PR description.
Removes the global nx.json hash, reasoning: the nx.json already has it's implicitDeps being hashed and the specific project in the nx.json projects object is also being hashed. This means we should not have to also hash the entire file.
Is that not true? If so I will leave the global hash in (as the PR stands)
Could you also cover the option in configuration.md (we have three version of this file)? |
Adds the ability to pass in number of nodes and current node to affected run commands so that target runs can be split evenly across nodes ISSUES CLOSED: nrwl#5283
…x hash commit files correctly
7bd252d
to
f68e371
Compare
@vsavkin to confirm the 3 files you are referring to are |
I believe this should be good to be reviewed again. Requested changes have been made. |
Thank you! I made some minor changes here: #5587 I'm going to merge that PR, so I'm closing this one. |
@vsavkin sounds good! I think you linked the wrong PR though haha. |
For anyone else looking for the PR victor is referring to: #6623 |
This pull request has already been merged/closed. If you experience issues related to these changes, please open a new issue referencing this pull request. |
I realize the hasher is super core to Nx and @vsavkin has mentioned before that it is not liberally changed but the linked issue is one of the things stopping us from using incremental building right now as we refactor a big legacy codebase with hundreds of libraries that will be merged which means we are constantly breaking the cache use to tsconfig.json/nx.json being updated. I hope this Pr is helpful in solving that issue.
ISSUES CLOSED: #5283
Current Behavior
Currently as discussed in issues closed, when affecting tsconfig/nx.json in ways that will not affect the outcome of targets those targets caches are broken. Example: When generating a library, the caches for all builds are broken which means everything needs to be rebuilt again.
Expected Behavior
When making changes to tsconfig and/or nx.json that should not affect the outcome of targets then those changes should not be considered for the caches hash.
This PR does two things:
compilerOptions.paths
of projects not currently being hashed, ie. only the current projects path configuration is now hashed, all others are discarded. This will prevent the generation of a new library breaking the cache for nx targets. Note: I added some typings for TsConfigJsonConfiguration because there was none and couldn't find any. I didn't add every property available in the file but can if that is something that is wanted.Related Issue(s)
Fixes #5283