Draft: FEAT - opt-in option to recursively find parents package.json on affected files from others package managers #395
Conversation
| The detection strategy for the affected packages, since this action only relies on affected files diff. | ||
| Possible values: `diff-only` (default) and `recursive-discovery` | ||
| required: true | ||
| default: diff-only |
There was a problem hiding this comment.
I honestly think this should probably be opt-out. There's a chance it ultimately detects a package.json which isn't managed by changesets, so we probably do need to provide a way to turn it off, but I think what we've discussed so far is strictly an improvement if you don't run into edge cases with monorepos not including all the packages in a repo.
There was a problem hiding this comment.
yeah, I agree with you
by know, maybe I'm wrong but this action currently dont relies on workspaces right? only in changeset/config.json private field. so even now can be false positives, as changesets id being generated by this action for this edge cases.
since dependabot and maybe renovate (as I think) only updates files that is about dependency management and nothing more, we can make also the resolution with micromatch/minimatch or any other, as an opt-out option
There was a problem hiding this comment.
Not sure what you mean about minimatch, but no, neither this action nor changeset relies on workspaces, there are a couple repos I have which aren't monorepos at all but manage releases using changesets just fine.
There was a problem hiding this comment.
There is some logic that involves workspaces, because whether the repo is a monorepo or not impacts which packages in the repo are valid for inclusion in a changeset (specifically, the root package.json) so this action isn't ignorant of them, but they aren't required.
There was a problem hiding this comment.
Not sure what you mean about minimatch, but no, neither this action nor
changesetrelies on workspaces, there are a couple repos I have which aren't monorepos at all but manage releases using changesets just fine.
changeset does not relies directly on the workspaces field, it relies however in the @manypkg/get-packages, maintained by changesets member
There was a problem hiding this comment.
after getting the monorepo packages, changesets does a filter for ignored packages
this is the function that changesets relies for finding package.jsons
https://github.com/Thinkmill/manypkg/blob/main/packages/get-packages/src/index.ts
you can see that its relies on "tool" dependency injection, and the NpmTool expands the glob for the workspaces field
There was a problem hiding this comment.
fyi:
to be more precise, actually changesets suports the two approaches: rush (without root package.json but with rush config file) and workspaces for monorepos
|
Any chances this could also support Renovate updates to pnpm-workspace:catalogs? |
|
@0xar-ds I suspect I know where you're going with this, and I suspect this would need to be it's own feature, it won't be covered automatically by what this feature request is attempting. Can you open a new issue with more details of what you'd expect to happen and how that differs from what does happen currently? |
#497 lmk if you need any further research/help |
3 participants
Resolves #394