Open
Conversation
ecraig12345
force-pushed
the
ecraig/boring-pancakes
branch
from
bb1c32e to
48bc2a6
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
(Same as #1157, but boring/clearer naming 🚫 🥞 😭)
When packing packages to a path, it turns out it may be useful or necessary to group layers of the tree together rather than using sequential ordering.
This PR adds a new option
packStyle: 'sequential' | 'layer'. The new option refers to packages from each layer of the graph that can be published in parallel. The first layer will be the leaf packages with no dependencies, and the last will be the root packages that depend on all others. The layers go in numbered subfolders underpackToPath.The layering uses Kahn's algorithm for BFS to extract the layers in O(V+E). (Apparently LLMs are good at choosing and writing algorithms thanks to the many code examples online...)
If possible, layers are computed based on only the set of published packages. This should be safe with beachball's default behaviors of bumping dependents, but layers will be computed over the full graph under any of the following conditions which might cause missing edges. (Not 100% sure this is necessary, but not sure how to disprove it either...)
bumpDepsis falsescopeis setnewPackagesdependentChangeTypeset to "none"In either case,
devDependenciesare ignored when computing the graph since they can't break published packages. This should improve improve efficiency and potentially condense the resulting layers slightly.I also replaced usage of the
toposortpackage with the new layer logic, since they effectively do the same thing (exact ordering may vary, but the topological relationships are handled either way).Currently, there's only VERY basic cycle handling: all cycles are grouped together on a final layer, regardless of any interdependencies. This should be fine since the
toposortpackage previously used by beachball doesn't handle cycles at all, which implies that repos publishing with beachball don't have cycles. (Tarjan's strongly connected components algorithm could be added at the end to break cycles into more layers if needed in the future, but it's a lot of extra complexity.)