Skip to content

Conversation

@davidfirst
Copy link
Member

@davidfirst davidfirst commented Oct 28, 2025

Summary

Fixes an issue where force:true dependencies were being lost during bare-scope lane merges.

When merging lanes in bare-scope with dependency updates, dependencies with force:true (whether set via bit dependencies set or workspace variants) were not being preserved in the merged config. This only affected merges that introduced dependency changes.

Additionally, handles the case where a dependency was explicitly removed on main via bit dependencies unset - ensuring it's properly removed during merge even if it was set on the lane. E2E tests confirm this works for both bare-scope and workspace merges.

Changes

Architecture

  • Processing happens in ONE place: merging.main.runtime.ts:applyVersion()
  • When mergedConfig is created from config merger, we immediately:
    1. Merge ALL scope dependencies with force:true (not just __specific: true)
    2. Filter out deletion markers (version: '-')
  • Both workspace and bare-scope merges read the already-processed config from unmergedComponents
  • No code duplication - single source of truth
  • The processed config (with scope force:true deps merged and deletion markers filtered) is written to unmerged.json. During snap, this config is used directly without reprocessing. Previously, unmerged.json lacked scope data, making dependency deletion handling complex and requiring separate logic for workspace vs bare-scope merges.

Force:true policy preservation

Deleted dependency handling

  • Added detection in component-config-merger.ts for dependencies deleted via bit dependencies unset
  • When a dependency exists in base and current but not in other (main), it's marked with version: '-'
  • Added filterDeletedDependenciesFromConfig() to remove deletion markers before saving
  • Deletes empty collections to avoid downstream issues
  • Ensures deleted dependencies don't appear in the final config

unmerged.json file size

  • Only stores manually-set dependencies (force: true) from scope in merged config
  • Auto-detected dependencies from scope (force: false) are not stored in unmerged.json
  • Auto-detected dependencies from the config merge itself are still stored
  • Keeps unmerged.json size reasonable
…re-scope merge

Fixes an issue where scope-specific dependencies (set via `bit dependencies set`) were being lost during bare-scope lane merges when the merge introduced dependency changes.

## Changes

### Scope-specific policy preservation
- Added logic in `merging.main.runtime.ts:applyVersion()` to merge scope-specific dependencies into merged config right before saving to unmergedComponents
- Scope-specific dependencies (marked with `__specific: true`) are preserved with `force: true` flag
- Merge config takes precedence when dependencies exist in both sources

### Deleted dependency handling
- Added detection in `component-config-merger.ts` for dependencies deleted via `bit dependencies unset`
- When a dependency exists in base and current but not in other (main), it's marked with `version: '-'`
- Deletion markers are filtered out before saving to ensure clean config

### Architecture
- Processing happens in ONE place: when mergedConfig is created and saved to unmergedComponents
- Both workspace and bare-scope merges read the already-processed config
- No code duplication - single source of truth for merge logic
- Only stores manually-set dependencies (`force: true`) in config; auto-detected deps are recalculated

## Test Scenarios

1. **Scope-specific dep preserved**: Dependency set via `bit dependencies set` on lane is preserved when main is merged to lane
2. **Deleted dep respected**: Dependency unset on main via `bit dependencies unset` is properly removed during merge, even if it was set on lane
3. **Auto-detected dep updated**: Regular dependencies are updated to versions from merged branch as expected

This ensures scope-specific policy is preserved while respecting explicit deletions during lane merges.
When merging scope-specific dependencies into merged config, convert
object format to array format to match config-merger expectations.
Also ensure empty arrays/objects are deleted to prevent downstream errors.
…format consistency

- Remove __specific check to handle all force:true dependencies (both from 'bit deps set' and workspace variants)
- Convert object format to array format when merging policies to maintain consistency expected by config-merger
- Ensures all dependency types use array format after merge to prevent 'forEach is not a function' errors
- Export PolicyDependency type from config-merger
- Use typed PolicyDependency[] instead of any[] in addScopePolicyToMergedArray
- Remove dependencyId fallback (only use name field)
- Add explicit types to mergedPolicy and conflictedPolicy objects
Explain why this method is necessary - without it, explicitly set dependencies
from the model would be ignored when mergeConfig has a policy. This is similar
to how 'bit deps set' preserves previous dependencies by copying them to .bitmap.
…ergeScopeSpecificDepsPolicy

Update comments that referenced the old method name to reference the new method
that handles the same functionality in merging.main.runtime
…sPolicy

The config-merger always returns policy in array format (Record<string, PolicyDependency[]>),
so the else branch handling object format was unreachable dead code. Removed it to match
the actual behavior and fix TypeScript errors with the typed mergeConfigPolicy.
… arrays

Remove dead code that handled object format and null checks. The policy is always
in array format (Record<string, PolicyDependency[]>) after config-merger, so we only
need to filter the arrays for deletion markers.
@davidfirst davidfirst changed the title fix: preserve scope-specific policy during bare-scope merge Oct 29, 2025
@davidfirst davidfirst merged commit dd1f519 into master Oct 29, 2025
11 checks passed
@davidfirst davidfirst deleted the fix/preserve-scope-specific-policy-during-merge branch October 29, 2025 17:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

3 participants