Skip to content
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

Conversation

yharaskrik
Copy link
Contributor

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:

  1. 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.
  2. Hashes the entire tsconfig file except the 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

@vercel
Copy link

vercel bot commented May 7, 2021

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/nrwl/nx-dev/FZhgCeWvUUamuKqDbEC5iQQ7N6b3
✅ Preview: https://nx-dev-git-fork-yharaskrik-jaybell-remove-entire-ts-7e04be-nrwl.vercel.app

@manfredsteyer
Copy link
Contributor

I love the idea!

@vsavkin vsavkin self-assigned this May 18, 2021
@vsavkin
Copy link
Member

vsavkin commented May 27, 2021

Thank you for the PR!

  1. We have added an ability to provide custom hasher for executors (e.g., packages/linter/src/executors/eslint/hasher.ts). Different use case but somewhat relevant.

  2. As you probalby have noticed, we no longer hash the whole nx.json, but only the relevant bits. So the only thing in question is tsconfig.base.json.

  3. At this point, only adding a new lib will invalidate the cache (cause of tsconfig), updating the lib won't invalidate the cache for the whole workspace. Your tsconfig change will fix it but it assumes that project name is used in tsconfig, which might not be the case. You can use any mappings you want in your tsconfig, they don't have to match the project name. So it can be a breaking change for "unusual" workspaces.

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?

@yharaskrik
Copy link
Contributor Author

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!

@yharaskrik yharaskrik force-pushed the jaybell/remove-entire-tsconfig-from-hasher branch from b56bfef to 8dd8b43 Compare May 27, 2021 22:45
@yharaskrik
Copy link
Contributor Author

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.

Copy link
Member

@vsavkin vsavkin left a 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 };
});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why was hashGlobalConfig removed?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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)

packages/workspace/src/core/hasher/hasher.ts Outdated Show resolved Hide resolved
packages/workspace/src/core/hasher/hasher.ts Outdated Show resolved Hide resolved
packages/tao/src/shared/tsconfig.ts Outdated Show resolved Hide resolved
@vsavkin
Copy link
Member

vsavkin commented Jul 2, 2021

Could you also cover the option in configuration.md (we have three version of this file)?

@yharaskrik yharaskrik force-pushed the jaybell/remove-entire-tsconfig-from-hasher branch from 7bd252d to f68e371 Compare July 5, 2021 02:16
@yharaskrik yharaskrik requested a review from vsavkin July 5, 2021 02:16
@yharaskrik
Copy link
Contributor Author

@vsavkin to confirm the 3 files you are referring to are angular/../configuration.md, react/../configuration.md and node/.../configuration.md?

@yharaskrik
Copy link
Contributor Author

I believe this should be good to be reviewed again. Requested changes have been made.

@vsavkin
Copy link
Member

vsavkin commented Aug 5, 2021

Thank you! I made some minor changes here: #5587

I'm going to merge that PR, so I'm closing this one.

@vsavkin vsavkin closed this Aug 5, 2021
@yharaskrik
Copy link
Contributor Author

@vsavkin sounds good! I think you linked the wrong PR though haha.

@yharaskrik
Copy link
Contributor Author

For anyone else looking for the PR victor is referring to: #6623

@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[v12] Incremental building without taking into account global files does not work as expected
3 participants