Closed Pavel-Sulimau closed 5 months ago
Hey @Salakar, @spydon, looking forward to your feedback on the current suggestion.
Lgtm! The only thing missing is an update about this behaviour in the docs
Thanks for the feedback, I gave this an update as well! I couldn't preview the change locally though because of https://github.com/invertase/docs.page/issues/262, but I believe we should be good as the doc change was a tiny one and as it should be previewable in the PR itself.
I'm not sure If I should also update https://melos.invertase.dev/guides/migrations section and if it should be part of this PR.
@spydon, let me know please, if there is anything else preventing the PR from being merged.
@spydon, let me know please, if there is anything else preventing the PR from being merged.
Just checking if there is anyone else that would like to review this, otherwise I'll merge it tonight. :)
@Pavel-Sulimau thanks for your contribution, it's now released in Melos 4.1.0 :)
Hey @Pavel-Sulimau, can you share your approach for solving your use-case that you mentioned above? We also have the same use-case. Are you using --diff for achieving it? In our case it's not working correctly anymore due to this issue https://github.com/invertase/melos/issues/557
Thanks
Hey @xsahil03x, sorry for the late response.
We're using a customized way (some scripting in Github Actions) to detect which packages (and their dependencies) are affected by changes in a Pull Request, then we set a list of names of the affected packages to MELOS_PACKAGES
env variable to scope the CI checks.
But we're going to migrate from that solution to using the melos-dff!
I'm also happy to see the diff functionality was recently fixed/improved.
Description
There are 2 key changes here:
melos run
command now also takesMELOS_PACKAGES
value into account.MELOS_PACKAGES
is not used instead of filters, but it adds or replaces thescope
in thePackageFilters
.Considering the current definition of
MELOS_PACKAGES
that says 'This bypasses all filtering flags if defined.' the current change looks like a breaking change to me.A bit more context: We have quite a big monorepo (100+ packages) on my current project. In our CI pipeline, we trigger the CI checks for certain subfolders/packages (based on which areas are affected by a PR). We already have this kind of setup running with Melos 2.9, but it was achieved by different means, and we'd love to migrate to the latest version of Melos. With Melos 4.0 it looks like the proposed change to
MELOS_PACKAGES
is the easiest way to achieve the granularity desired in our case.Type of Change
feat
-- New feature (non-breaking change which adds functionality)fix
-- Bug fix (non-breaking change which fixes an issue)!
-- Breaking change (fix or feature that would cause existing functionality to change)refactor
-- Code refactorci
-- Build configuration changedocs
-- Documentationchore
-- Chore