[rush] Let's document best practices for WSL + Rush
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 35/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- git, linux
- Domain
- documentation, operating-systems
Research direction
Start with the linked Zulip thread and the referenced getRepoStateAsync code in libraries/package-deps-hash/src/getRepoState.ts. Gather confirmed WSL+Rush recommendations or workarounds, then use them to create the website documentation page. Done means the guidance addresses the incremental-build behavior and provides practical best practices.
Written by the indexing model from the issue text.
Description
Relatively few people are using Windows Subsystem for Linux (WSL) with Rush.
In a recent Zulip thread, @Akres encountered some problems where Rush's incremental builds were not calculated correctly:
The incremental build feature works, but sometimes triggers a full rebuild while nothing has changed. That wouldn't be so bad. The flip side of the same issue is that when there is a change, the package sometimes does not rebuild, which makes it largely unusable.
I have done a bit of digging and found that the issue happens in https://github.com/microsoft/rushstack/blob/main/libraries/package-deps-hash/src/getRepoState.ts#L309
getRepoStateAsyncI did some debugging and found that the
git statuscall quite frequently (about 50% of times, for me) returns an empty output, so the hashes, which this function returns, are that of the repo in its unmodified state.I was pointed in this direction by https://stackoverflow.com/a/55692650 this comment. It seems that the issue really comes from two git commands running simultaneously, because when I tried to play with the code that I have locally and I serialized the calls, the issue disappeared.
Reply to this thread with any wisdom, recommendations, or workarounds for WSL+Rush. Then we can write up a website documentation page providing guidance for best practices with WSL.
- Dominant language
- TypeScript
- Stars
- 39
- Forks
- 86
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 2
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/rushstack-websites
-
Difficulty 1/5 Under an hour Newbie friendliness 20/100
microsoft/rushstack-websites#318 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 38/100
microsoft/rushstack-websites#296 · 8 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
microsoft/rushstack-websites#280 · 2 comments · 1 reaction ·
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
microsoft/rushstack-websites#279 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
microsoft/rushstack-websites#226 ·
All issues in microsoft/rushstack-websites
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
EclipseFdn/open-vsx.org#13385 · 1 comment ·
-
S: triage
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
fix(errors): EHOSTUNREACH from a happy-eyeballs connect is reported as a resolver error (STAMP-80) Open
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
snapshot-labs/stamp#666 ·
-
vangogh
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
knaw-huc/textannoviz#691 ·