synchronize-with-npm works by comparing the latest commit to the one previous to that one to determine which packages to publish.
However, we noticed when a pull request isn't squashed before getting merged, the merge commit will compare itself with the previous commit which in the synchronize-with-npm action would result in no changes and therefore not publish any packages.
To mitigate this oversight, we have come up with a proposal:
Current Action Workflow
get all the files that have changed
find all the relevant package.json of those files to determine from where the action must run publish
filter out the directories from the default list and ignore arguments from the workflow
loop over the list of directories
skip if private or if the package version has already been published
publish and push git tag
Possible Solution
find all package.json in the repository (excluding those in node_modules)
remove private packages
check each package@version on npm registry to determine if it should publish
Why Did It Filter In The First Place?
We have an action for publishing previews which would benefit from knowing which files have changed so that we don't publish every package for each pull request for each commit. Then the synchronize-with-npm action was born and took a lot of its logic from the preview action, but now we realize the filtering is not necessary for publishing releases.
Any Downfalls?
We can still integrate the ignore argument to prevent certain directories and its sub-directories from publishing but that seems redundant because users will be expected to be more explicit with which packages they want publishing so it'll be rare for a package to be published by mistake. The same goes for the logic of preventing sub-directory packages from publishing; this is actually a plus because the new approach would resolve this issue and get rid of that caterpillar.
Context
synchronize-with-npmworks by comparing the latest commit to the one previous to that one to determine which packages to publish.However, we noticed when a pull request isn't squashed before getting merged, the merge commit will compare itself with the previous commit which in the
synchronize-with-npmaction would result in no changes and therefore not publish any packages.To mitigate this oversight, we have come up with a proposal:
Current Action Workflow
package.jsonof those files to determine from where the action must run publishPossible Solution
Why Did It Filter In The First Place?
We have an action for publishing previews which would benefit from knowing which files have changed so that we don't publish every package for each pull request for each commit. Then the
synchronize-with-npmaction was born and took a lot of its logic from the preview action, but now we realize the filtering is not necessary for publishing releases.Any Downfalls?
We can still integrate the
ignoreargument to prevent certain directories and its sub-directories from publishing but that seems redundant because users will be expected to be more explicit with which packages they want publishing so it'll be rare for a package to be published by mistake. The same goes for the logic of preventing sub-directory packages from publishing; this is actually a plus because the new approach would resolve this issue and get rid of that caterpillar.