-
Notifications
You must be signed in to change notification settings - Fork 57
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: enable framework detection on js workspace root #5853
base: main
Are you sure you want to change the base?
feat: enable framework detection on js workspace root #5853
Conversation
Fixes FRB-793 It is valid to have a monorepo (PNPM workspace) but still have a site on the root of it This enables the support of still having detection inside monorepo packages but additionally on the root as well
Quality Gate passedIssues Measures |
for (const result of results) { | ||
for (let i = 0, max = rootFrameworks.length; i < max; i++) { | ||
if (isEqual(result.detected, rootFrameworks[i].detected)) { | ||
rootFrameworkMutex.runExclusive(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.
can you briefly explain why mutex is needed here (and only here)?
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.
also - shouldn't this exclusive run be wider? index of item to remove is figured before entering exclusive mode and if mutex is here at all, presumably multiple concurrent runs can execute this code, so index figured out before acquiring mutex might no longer be correct because since figured out i
something else might have mutated things?
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.
oh that's a good point!
yea because we run this highly in parallel so mutating the array is dangerous in a concurrent highly async loop!
* @param callback Function to be run exclusively. | ||
* @returns The return value of `callback`. | ||
*/ | ||
async runExclusive<T>(callback: () => Promise<T>) { |
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.
could the same be achieved with just p-limit
using 1
as concurrency? It seems like p-limit
is already indirect dependency of build-info
:
npm list p-limit
[email protected] /Users/misiek/dev/netlify-build
└─┬ @netlify/[email protected] -> ./packages/build-info
├─┬ @bugsnag/[email protected]
│ └─┬ [email protected]
│ └─┬ [email protected]
│ └─┬ [email protected]
│ └─┬ [email protected]
│ └── [email protected]
├─┬ @vitest/[email protected]
│ └─┬ [email protected]
│ └─┬ [email protected]
│ └─┬ [email protected]
│ └─┬ [email protected]
│ └── [email protected]
├─┬ [email protected]
│ └─┬ [email protected]
│ └─┬ [email protected]
│ └── [email protected] deduped
└─┬ [email protected]
└─┬ @vitest/[email protected]
└── [email protected]
(no strong preference here, just checking)
Fixes FRB-793
It is valid to have a monorepo (PNPM workspace) but still have a site at the root of it.
This enables the support of still having detection inside monorepo packages but additionally on the root as well.
For us to review and ship your PR efficiently, please perform the following steps:
we can discuss the changes and get feedback from everyone that should be involved. If you`re fixing a typo or
something that`s on fire 🔥 (e.g. incident related), you can skip this step.
your code follows our style guide and passes our tests.
A picture of a cute animal (not mandatory, but encouraged)