feat!: make run script use melos_packages env variable scope

[Pavel-Sulimau]

Description

There are 2 key changes here:

• melos run command now also takes MELOS_PACKAGES value into account.
• MELOS_PACKAGES is not used instead of filters, but it adds or replaces the scope in the PackageFilters.

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 refactor
• ✅ ci -- Build configuration change
• 📝 docs -- Documentation
• 🗑️ chore -- Chore

[CLAassistant]

All committers have signed the CLA.

[Pavel-Sulimau]

Hey @Salakar, @spydon,
looking forward to your feedback on the current suggestion.

[spydon]

Overall it looks good to me, I've never used that way of filtering though so I might have overlooked something

[spydon]

Lgtm! The only thing missing is an update about this behaviour in the docs

[Pavel-Sulimau]

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 invertase/docs.page#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]

@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. :)

[spydon]

@Pavel-Sulimau thanks for your contribution, it's now released in Melos 4.1.0 :)

[xsahil03x]

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 #557

Thanks

[Pavel-Sulimau]

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.