chore: add basic project constraints #5152
Conversation
|
Branch previewReview the following VRT differencesWhen a visual regression test fails (or has previously failed while working on this branch), its results can be found in the following URLs:
If the changes are expected, update the |
Tachometer resultsCurrently, no packages are changed by this PR... |
Lighthouse scores
What is this?Lighthouse scores comparing the documentation site built from the PR ("Branch") to that of the production documentation site ("Latest") and the build currently on Transfer Size
Request Count
|
Pull Request Test Coverage Report for Build 13726468939Details
💛 - Coveralls |
| workspace.set('main', './src/index.js'); | ||
| workspace.set('module', './src/index.js'); |
There was a problem hiding this comment.
Some of our packages do not have a different entry point other than index.js (e.g. clear-button or opacity-checkerboard), so we might need to account for these exceptions.
There was a problem hiding this comment.
There's a couple different ways to handle it, would love your thoughts:
- We wrap the set command in a check first so it only adds the value if it's not already set. This prevents overwriting a value however it also negates the benefit of being able to manage the consistency of all packages.
- We add an exclusion for those packages that we know have exceptions (ideal if those exceptions are consistent to each other).
There was a problem hiding this comment.
Good call! I think having an explicit list of exceptions (like clear-button and opacity-checkerboard etc) makes sense while keeping everything else consistent. That way, we don’t override anything we shouldn’t. What do you think?
castastrophe
force-pushed
the
castastrophe/chore-add-constraints-settings
branch
2 times, most recently
from
31281f7 to
eb1f4d4
Compare
| * Fetch a list of all the component workspaces using a glob pattern | ||
| * @type {string[]} components | ||
| */ | ||
| const components = fg.sync('packages/*', { |
There was a problem hiding this comment.
fg.sync() is called synchronously here, which might block execution since there are a lot of packages.
can we use an async function and await fg()
| const localPackages = Object.keys( | ||
| workspace.manifest.peerDependencies | ||
| ) | ||
| .filter((pkg) => Yarn.workspace({ ident: pkg })) |
There was a problem hiding this comment.
Yarn.workspace({ ident: pkg }) is called twice on a single package here. can we reuse the result and call it once?
const localPackages = Object.keys(workspace.manifest.peerDependencies)
.map((pkg) => Yarn.workspace({ ident: pkg }))
.filter(Boolean);| * Process the components workspaces with component-specific configuration | ||
| */ | ||
| if (isComponent) { | ||
| const folderName = workspace.cwd?.split('/')?.[1]; |
There was a problem hiding this comment.
A more robust approach like this path.basename(workspace.cwd) would be helpful?
| 'design-system', | ||
| 'spectrum', | ||
| 'adobe', | ||
| 'adobe-spectrum', | ||
| 'web components', | ||
| 'web-components', | ||
| 'lit-element', | ||
| 'lit-html', |
There was a problem hiding this comment.
Can we add the values to a new array like baseKeyWords and use this? Saves re-allocation of new array everytime keywords is called!
castastrophe
force-pushed
the
castastrophe/chore-add-constraints-settings
branch
from
eb1f4d4 to
2b8029d
Compare
Description
Yarn constraints allow enforcement of rules across workspaces in a project.
This update does not apply the constraints, but rather defines them so they can be reported. We can do a separate PR to apply the updates via:
yarn constraints --fix.Motivation and context
This update adds package.json standardization rules such as:
For non-component packages, this update expects packages:
Component-specific packages expect:
How has this been tested?
yarn constraints: expect it to report the following proposed fixesTypes of changes
Checklist
Best practices
This repository uses conventional commit syntax for each commit message; note that the GitHub UI does not use this by default so be cautious when accepting suggested changes. Avoid the "Update branch" button on the pull request and opt instead for rebasing your branch against
main.