-
Notifications
You must be signed in to change notification settings - Fork 609
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
[rush] Subspace Configuration Files #4442
Conversation
libraries/rush-lib/src/api/packageManager/PnpmPackageManager.ts
Outdated
Show resolved
Hide resolved
libraries/rush-lib/src/api/packageManager/PnpmPackageManager.ts
Outdated
Show resolved
Hide resolved
Co-authored-by: David Michon <[email protected]>
* This specifies whether or not to use the "subspaces" feature in rush. This allows grouping of | ||
* projects into discrete workspaces known as "subspaces". | ||
*/ | ||
"enabled": false, |
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.
Should these properties have a /*[LINE "HYPOTHETICAL"]*/
prefix?
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.
Yes, if they are optional in the JSON schema.
But I think /*[LINE "HYPOTHETICAL"]*/
maybe should NOT be applied to the feature-gating setting ("useSubspaces"
? "enabled"
?) even if it is optional, since we want a casual observer to see that it is false
without wondering what is the default value.
if (FileSystem.exists(subspaceConfigLocation)) { | ||
// Try getting a subspace configuration | ||
this.subspaceConfiguration = SubspaceConfiguration.loadFromConfigurationFile(subspaceConfigLocation); | ||
} |
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.
Can you rename loadFromConfigurationFile
to tryLoadFromConfigurationFile
and just return undefined if the file doesn't exist?
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.
And ideally this load should be async.
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.
Changed to tryLoadFromConfigurationFile
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.
Can this be made async?
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.
(If the other similar Rush functions are not already async
, then we shouldn't insist that Will fixes it in this PR.)
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.
I'm a bit confused as to why this would be async - it only uses a call to FileSystem.exists
, which as far as I can tell is a synchronous action, so if there are no asynchronous calls within the tryLoadFromConfigurationFile
function, what purpose would labelling it async be?
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.
There is a FileSystem.existsAsync
, and there is a JsonFile.loadAndValidateAsync
. Anything that touches the filesystem (including JSON file loading) should ideally be async to allow those calls to be parallelized.
"type": "boolean" | ||
}, | ||
"splitWorkspaceCompatibility": { | ||
"description": "(DEPRECATED) A depreciated option that allows individual subspaces to be configured at the package level if that package is the only project in the subspace. Used to help migrate from a split workspace state.", |
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.
We're introducing this with a deprecated feature? That doesn't seem right.
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.
@iclanton This feature will be used internally by TikTok to incrementally migrate a huge monorepo that is using the earier #3481 branch. After the migration is complete, the setting will be removed. Because it is a company-specific concern, it seemed inappropriate to explain that in the schema comment.
try { | ||
resolvedSubspaceJsonFilename = trueCasePathSync(resolvedSubspaceJsonFilename); | ||
} catch (error) { | ||
/* ignore errors from true-case-path */ |
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.
Discarding every possible error is always a suspicious practice.
Looking up the implementation in true-case-path/index.js, there are actually 3 separate errors that it can throw (aside from indirect errors such as Cannot read properties of undefined
):
[true-case-path]: Called with ${filePath}, but no matching file exists
[true-case-path]: basePath argument must be absolute. Received "${basePath}"
[true-case-path]: filePath must be relative when used with basePath
The first one is probably what we're hoping to catch, whereas inadvertently catching the others would probably hide a bug.
I found /* ignore errors from true-case-path */
in two other places in the Rush code base, so probably @william2958 is simply copying that practice. Thus addressing this is out of scope for this PR.
But in the future maybe someone should move true-case-path
into a library function and invent a more correct solution for nonexistent files.
common/changes/@microsoft/rush/will-intro-subspace_2023-12-04-16-28.json
Outdated
Show resolved
Hide resolved
Co-authored-by: Ian Clanton-Thuon <[email protected]>
Co-authored-by: Ian Clanton-Thuon <[email protected]>
Co-authored-by: Ian Clanton-Thuon <[email protected]>
Co-authored-by: Ian Clanton-Thuon <[email protected]>
…16-28.json Co-authored-by: Pete Gonzalez <[email protected]>
Co-authored-by: Ian Clanton-Thuon <[email protected]>
Co-authored-by: Ian Clanton-Thuon <[email protected]>
@@ -185,7 +186,7 @@ export class InitAction extends BaseConfiglessRushAction { | |||
'rush.json' | |||
]; | |||
|
|||
const experimentalTemplateFilePaths: string[] = ['subspaces.json']; | |||
const experimentalTemplateFilePaths: string[] = [`common/config/rush/${RushConstants.subspacesFilename}`]; |
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.
Feels like the common/config/rush
part should also be in a const (or consts?) 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.
That string already appears throughout this file. Seems like it's probably out of scope for this PR.
Co-authored-by: Ian Clanton-Thuon <[email protected]>
Co-authored-by: Ian Clanton-Thuon <[email protected]>
Summary
This MR introduces the configuration files for the upcoming subspaces feature, who's RFC is located here: https://github.com/microsoft/rushstack/blob/octogonz/rfc-4320-rush-subspaces/common/docs/rfcs/rfc-4230-rush-subspaces.md
This MR sets up:
subspace.json
configuration file for individual subspaces (As well as accompanying schema).rush.json
to support subspace specification.Details
How it was tested
Currently being manually tested
Impacted documentation