Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
feat(generate:assertTags): Enable per package assert tagging configuration #23452
feat(generate:assertTags): Enable per package assert tagging configuration #23452
Changes from 6 commits
aadc2e0
c16f987
5e1ce1f
89ce236
3d5fee3
5c06f20
e55dd41
a67474c
2c8fe5c
137a6c2
472cf03
fbac2c2
18ae12c
c400e3c
46cfaa3
23cc67d
5a7b3dc
b2fca3d
9593d26
24efa74
01d79dc
240b8ab
3d42046
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Great observation. This is a side effect of the evolution of the code and the developers writing it. :)
@zhenmichael Let's chat about the specific ideas Craig shared and integrate them into the design for PackageCommand vnext. The most critical thing to decide in order to unblock this PR is where the per-package config should live (see other comments). Any enhancements to the selection/filtering should live in build-infrastructure with the new functions there. Some of the things called out here will likely be addressed as a side effect of building on the new selection/filtering stuff.
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 PackageCommand allowed passing both --releaseGroup and --package at the same time then we could use that to replace the regex filter. Thats likely the simplest solution since we could just pass in
--releaseGroup client --package @fluidframework/common-utils
instead of--all
.If we do want to keep the regex functionality, it can be kept and moved to PackageCommand along with its other filtering options.
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.
Supporting multiple selection flags seems trivial, so I'm going to try and make that change.
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.
This should do it: #23511
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.
Ahh, I see you're loading the package config here. I think putting it in package.json will be clearer and lets you get rid of some of this code since you can just get the config from the package directly.
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.
Are you suggesting to:
I think you mean 1, which makes sense, though I suspect it won't be less code just less over all coupling.
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 suggesting putting the settings in package.json, but not with the existing FlubConfig interface. Maybe it makes sense to use the
AssertTaggingConfig
interface? I was imagining something like this in the individual packages:We could get rid of the "flubCommandConfig" layer, and maybe that's a bad name anyway. I was trying to avoid adding a bunch of stuff at the top level, but I'm more pragmatic than principled in this case.
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.
Keeping the ability to have one config file cover all 13 packages in packages/test is useful, so I kept the use of cosmic config, but make it use its own config. THis should prevent this folder config from causing issues with any other configurations.
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.
Removing this caused many more packages to be processed, like test-dds-utils, test-runtime-utils and everything in packages/test . See the config files added to filter them out.