Initialize a Rush workspace for client SDKs

[bsiegel]

This PR creates a new Rush workspace, currently only containing the client SDKs. It includes several dependency version updates to align them across projects - this way, Rush can ensure that dependency versions for all of our packages remain in sync going forward.

Rush is configured to use pnpm as the package manager which provides several additional benefits. However Rush is not 100% compatible with the current version of pnpm (v3) so we should hold off merging this until that compatibility is added, or roll back to v2 of pnpm in rush.json

[weshaggard]

cc @Azure/azure-sdk-eng

[bterlson]

Some notes:

• main key of rollup-plugin-node-resolve is deprecated. Use mainFields instead.
• Seems like we have multiple versions of TypeScript. Probably not a major issue for now.
• rush test rebuilds the world after a rush build. Is this expected?
• rush add should really allow me to add local, unpublished packages (see: [rush] "rush add" should be able to add unpublished locally-linked projects microsoft/rushstack#991)
• Instructions for taking an unpublished dependency seems important. Process is, basically, manually update your package.json with the dependency and run rush update.
• VSCode seems to stomp on some things, resulting in permissions errors when doing e.g. rush update. I suspect it's automatic type acquisition. I think I've gotten to a good place by enabling "typescript.disableAutomaticTypeAcquisition" in my workspace, might be worth adding that suggestion to the readme.

[bterlson]

Played around with this (and built on it with #2373) and I like it lots. Happy to see this merged ASAP so we can start more refactorings like #2373.

[bsiegel]

• main key of rollup-plugin-node-resolve is deprecated. Use mainFields instead.

Fixed.

• Seems like we have multiple versions of TypeScript. Probably not a major issue for now.

This was always true. API Extractor v6 requires an old version. If we upgrade to v7 it will resolve this issue.

• rush test rebuilds the world after a rush build. Is this expected?

No, it's because we have many packages where the "test" script runs "build". We should clean this up in a followup PR.

• rush add should really allow me to add local, unpublished packages (see: Microsoft/web-build-tools#991)

😿 but for what it's worth you can edit the package.json manually and do rush update in this situation.

• Instructions for taking an unpublished dependency seems important. Process is, basically, manually update your package.json with the dependency and run rush update.

Good catch! Fixed.

• VSCode seems to stomp on some things, resulting in permissions errors when doing e.g. rush update. I suspect it's automatic type acquisition. I think I've gotten to a good place by enabling "typescript.disableAutomaticTypeAcquisition" in my workspace, might be worth adding that suggestion to the readme.

Added to the README. What are your feelings on checking in the .vscode/settings.json file with this change? I can see other settings being appropriate to commit as well, to help enforce some things repo-wide. If we want to make sure people don't keep getting diffs by making settings changes to their local workspace, we can keep the file .gitignored and force-add it to the working tree.

[bterlson]

I have a vague worry that there are other things in vscode doing npm install for you, but talking with @ramya-rao-a this may be the only place. I like disabling it in settings.json. I also kinda like the hack you mention to allow updating of local settings! It lets me configure my extensions I love that nobody else has 😊 But, I'll leave that up to you, I'm ok dealing with untracked changes as well.

[mikeharder]

A few general questions:

1. Should the Azure Pipelines YAML be updated to use the Rush commands for building, testing, etc?
2. How does build and test performance compare between the current "npm-run-all" solution and Rush? What, if anything, does Rush improve with respect to developer experience, either inner loop (incremental compilation) or outer loop (full compilation)?

[bterlson]

FWIW, my experience is full builds are much faster as it seems to skip things that are already built.

[mikeharder]

FWIW, my experience is full builds are much faster as it seems to skip things that are already built.

I will run a few before/after perf tests.

[bsiegel]

1. Should the Azure Pipelines YAML be updated to use the Rush commands for building, testing, etc?

Yep, I am planning to do that in a followup PR.

[weshaggard]

Sorry I accidentally posted this to another PR, not sure what happened, and I know this is already merged but I'm still curious about my question below.

Is there any hard rules about these files going into a folder called common? I ask mostly as for some of the other languages we have been putting similar engineering system type files under an "eng" directory.