@teambit/lanes 0.0.560 → 0.0.562
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/lanes.docs.mdx
CHANGED
|
@@ -25,15 +25,6 @@ The following describes the final implementation, which differs from the specifi
|
|
|
25
25
|
- (internal) cat lane object: `bit cat-lane <name>`
|
|
26
26
|
```
|
|
27
27
|
|
|
28
|
-
## Remaining tasks
|
|
29
|
-
|
|
30
|
-
- [ ] Remove components from a remote lane.
|
|
31
|
-
- [ ] Tag dependencies to include them in a lane.
|
|
32
|
-
- [ ] Test bit-fetch components
|
|
33
|
-
- [ ] Rename lanes: enable importing a lane after rename.
|
|
34
|
-
- [ ] Fix performance issue. Now it fetches all parents every time. It doesn't make sense.
|
|
35
|
-
- [ ] Fix performance issue. Now it traverses all parents to see if a hash in there.
|
|
36
|
-
|
|
37
28
|
## Important points
|
|
38
29
|
|
|
39
30
|
### Lane ID
|
|
@@ -99,5 +90,38 @@ Summary of when/what lanes data is saved per command:
|
|
|
99
90
|
### Remove component from a lane
|
|
100
91
|
|
|
101
92
|
Locally, to remove a component from a lane, use `bit remove` command. It will remove the component from the local lane-object.
|
|
102
|
-
This change won't affect the remote scope, even after exporting the lane.
|
|
93
|
+
This change won't affect the remote scope, even after exporting the lane.
|
|
94
|
+
This is becuase on the remote, the merge-lane process doesn't remove anything, only adds/changes components to the lane object.
|
|
103
95
|
Remember that by default when importing a lane, only the components on the workspace are part of the lane, so the same lane-object, locally can have less components than the remote and obviously in this case we don't want to remove them from the remote on export.
|
|
96
|
+
|
|
97
|
+
To mark a component as removed on the lane, use `bit remove --soft`, which will modify the component, mark it as removed, then, on the next snap+export, the remote will be updated.
|
|
98
|
+
Once a component is marked as removed, it won't be merged during `bit lane merge`, and won't be imported during `bit lane import`.
|
|
99
|
+
|
|
100
|
+
### Debug issues during merge
|
|
101
|
+
|
|
102
|
+
The merge operation performs 3-way merge to minimize the number of conflicts.
|
|
103
|
+
It searches the common parent of the current-snap and the other-snap. This parent-snap or base-snap is common to these two lanes.
|
|
104
|
+
For most case, it works as follows:
|
|
105
|
+
If the base and current has the same data but the other has different data, it means, the other made a change.
|
|
106
|
+
In which case, no need for conflicts, just bring the data from the other to the local.
|
|
107
|
+
On the other hand, if the base the other has the same data but the current has different data, then, the current made a change. No need to do anything.
|
|
108
|
+
Only when the current and the other, both are different, and both are different than the base, there is a conflict.
|
|
109
|
+
|
|
110
|
+
In case of merging lanes, and it's unclear why/how some changes were introduced or marked conflicted, go to the log to find out what is the base-snap and the other-snap.
|
|
111
|
+
The log message starts with "merging snaps details", and it lists per component-id the base-snap, current-snap and other-snap.
|
|
112
|
+
From here, you can investigate the data of each one of the snaps by running `bit cat-object -p <snap>`.
|
|
113
|
+
To make this process easier, there are some tools that can help. keep reading.
|
|
114
|
+
|
|
115
|
+
#### source code merges/conflicts
|
|
116
|
+
|
|
117
|
+
To find out when a change was introduced to a file or when a file was added/removed, run `bit log-file <file-path>`.
|
|
118
|
+
It might be helpful to create a new temorary workspace, import the other lane and run the same there.
|
|
119
|
+
This way, you get the full picture from both lanes when a change was introduced, and you can see whether it happened before and after the split from the base-snap.
|
|
120
|
+
Obviously, `bit log <comp-id> --one-line` is helpful here to see the distance from each lane from the base-snap.
|
|
121
|
+
|
|
122
|
+
#### dependencies merges/conflicts
|
|
123
|
+
|
|
124
|
+
Similar to file-changes, you can run `bit deps blame` to understhand when a dependency was introduced/deleted/changed from a component.
|
|
125
|
+
Here again, it'll be helpful to import to a new workspace the other lane and run the same there.
|
|
126
|
+
Also, becuase the dependencies merge is pretty complex, during the merge lots of valuable info is printed to the log.
|
|
127
|
+
However, to avoid the extra noise it is not logged as "debug" but as "trace". Before you run the merge, you can add `--log=trace` to see these messages on the screen.
|
|
@@ -1,5 +1,5 @@
|
|
|
1
|
-
import * as compositions_0 from '/home/circleci/Library/Caches/Bit/capsules/8891be5ad3d35bfc38b9cd90c0e05b598a5a55af/teambit.lanes_lanes@0.0.
|
|
2
|
-
import * as overview_0 from '/home/circleci/Library/Caches/Bit/capsules/8891be5ad3d35bfc38b9cd90c0e05b598a5a55af/teambit.lanes_lanes@0.0.
|
|
1
|
+
import * as compositions_0 from '/home/circleci/Library/Caches/Bit/capsules/8891be5ad3d35bfc38b9cd90c0e05b598a5a55af/teambit.lanes_lanes@0.0.562/dist/lanes.composition.js';
|
|
2
|
+
import * as overview_0 from '/home/circleci/Library/Caches/Bit/capsules/8891be5ad3d35bfc38b9cd90c0e05b598a5a55af/teambit.lanes_lanes@0.0.562/dist/lanes.docs.mdx';
|
|
3
3
|
|
|
4
4
|
export const compositions = [compositions_0];
|
|
5
5
|
export const overview = [overview_0];
|
package/lanes.docs.mdx
CHANGED
|
@@ -25,15 +25,6 @@ The following describes the final implementation, which differs from the specifi
|
|
|
25
25
|
- (internal) cat lane object: `bit cat-lane <name>`
|
|
26
26
|
```
|
|
27
27
|
|
|
28
|
-
## Remaining tasks
|
|
29
|
-
|
|
30
|
-
- [ ] Remove components from a remote lane.
|
|
31
|
-
- [ ] Tag dependencies to include them in a lane.
|
|
32
|
-
- [ ] Test bit-fetch components
|
|
33
|
-
- [ ] Rename lanes: enable importing a lane after rename.
|
|
34
|
-
- [ ] Fix performance issue. Now it fetches all parents every time. It doesn't make sense.
|
|
35
|
-
- [ ] Fix performance issue. Now it traverses all parents to see if a hash in there.
|
|
36
|
-
|
|
37
28
|
## Important points
|
|
38
29
|
|
|
39
30
|
### Lane ID
|
|
@@ -99,5 +90,38 @@ Summary of when/what lanes data is saved per command:
|
|
|
99
90
|
### Remove component from a lane
|
|
100
91
|
|
|
101
92
|
Locally, to remove a component from a lane, use `bit remove` command. It will remove the component from the local lane-object.
|
|
102
|
-
This change won't affect the remote scope, even after exporting the lane.
|
|
93
|
+
This change won't affect the remote scope, even after exporting the lane.
|
|
94
|
+
This is becuase on the remote, the merge-lane process doesn't remove anything, only adds/changes components to the lane object.
|
|
103
95
|
Remember that by default when importing a lane, only the components on the workspace are part of the lane, so the same lane-object, locally can have less components than the remote and obviously in this case we don't want to remove them from the remote on export.
|
|
96
|
+
|
|
97
|
+
To mark a component as removed on the lane, use `bit remove --soft`, which will modify the component, mark it as removed, then, on the next snap+export, the remote will be updated.
|
|
98
|
+
Once a component is marked as removed, it won't be merged during `bit lane merge`, and won't be imported during `bit lane import`.
|
|
99
|
+
|
|
100
|
+
### Debug issues during merge
|
|
101
|
+
|
|
102
|
+
The merge operation performs 3-way merge to minimize the number of conflicts.
|
|
103
|
+
It searches the common parent of the current-snap and the other-snap. This parent-snap or base-snap is common to these two lanes.
|
|
104
|
+
For most case, it works as follows:
|
|
105
|
+
If the base and current has the same data but the other has different data, it means, the other made a change.
|
|
106
|
+
In which case, no need for conflicts, just bring the data from the other to the local.
|
|
107
|
+
On the other hand, if the base the other has the same data but the current has different data, then, the current made a change. No need to do anything.
|
|
108
|
+
Only when the current and the other, both are different, and both are different than the base, there is a conflict.
|
|
109
|
+
|
|
110
|
+
In case of merging lanes, and it's unclear why/how some changes were introduced or marked conflicted, go to the log to find out what is the base-snap and the other-snap.
|
|
111
|
+
The log message starts with "merging snaps details", and it lists per component-id the base-snap, current-snap and other-snap.
|
|
112
|
+
From here, you can investigate the data of each one of the snaps by running `bit cat-object -p <snap>`.
|
|
113
|
+
To make this process easier, there are some tools that can help. keep reading.
|
|
114
|
+
|
|
115
|
+
#### source code merges/conflicts
|
|
116
|
+
|
|
117
|
+
To find out when a change was introduced to a file or when a file was added/removed, run `bit log-file <file-path>`.
|
|
118
|
+
It might be helpful to create a new temorary workspace, import the other lane and run the same there.
|
|
119
|
+
This way, you get the full picture from both lanes when a change was introduced, and you can see whether it happened before and after the split from the base-snap.
|
|
120
|
+
Obviously, `bit log <comp-id> --one-line` is helpful here to see the distance from each lane from the base-snap.
|
|
121
|
+
|
|
122
|
+
#### dependencies merges/conflicts
|
|
123
|
+
|
|
124
|
+
Similar to file-changes, you can run `bit deps blame` to understhand when a dependency was introduced/deleted/changed from a component.
|
|
125
|
+
Here again, it'll be helpful to import to a new workspace the other lane and run the same there.
|
|
126
|
+
Also, becuase the dependencies merge is pretty complex, during the merge lots of valuable info is printed to the log.
|
|
127
|
+
However, to avoid the extra noise it is not logged as "debug" but as "trace". Before you run the merge, you can add `--log=trace` to see these messages on the screen.
|
|
Binary file
|
package/package.json
CHANGED
|
@@ -1,12 +1,12 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@teambit/lanes",
|
|
3
|
-
"version": "0.0.
|
|
3
|
+
"version": "0.0.562",
|
|
4
4
|
"homepage": "https://bit.dev/teambit/lanes/lanes",
|
|
5
5
|
"main": "dist/index.js",
|
|
6
6
|
"componentId": {
|
|
7
7
|
"scope": "teambit.lanes",
|
|
8
8
|
"name": "lanes",
|
|
9
|
-
"version": "0.0.
|
|
9
|
+
"version": "0.0.562"
|
|
10
10
|
},
|
|
11
11
|
"dependencies": {
|
|
12
12
|
"chalk": "2.4.2",
|
|
@@ -19,35 +19,35 @@
|
|
|
19
19
|
"@teambit/harmony": "0.4.6",
|
|
20
20
|
"@teambit/bit-error": "0.0.402",
|
|
21
21
|
"@teambit/component-version": "0.0.408",
|
|
22
|
-
"@teambit/lane-id": "0.0.
|
|
23
|
-
"@teambit/scope": "0.0.
|
|
24
|
-
"@teambit/lanes.ui.models.lanes-model": "0.0.
|
|
25
|
-
"@teambit/cli": "0.0.
|
|
26
|
-
"@teambit/workspace": "0.0.
|
|
27
|
-
"@teambit/express": "0.0.
|
|
28
|
-
"@teambit/logger": "0.0.
|
|
29
|
-
"@teambit/graphql": "0.0.
|
|
30
|
-
"@teambit/component-compare": "0.0.
|
|
31
|
-
"@teambit/component-writer": "0.0.
|
|
32
|
-
"@teambit/component": "0.0.
|
|
33
|
-
"@teambit/export": "0.0.
|
|
34
|
-
"@teambit/importer": "0.0.
|
|
35
|
-
"@teambit/lanes.entities.lane-diff": "0.0.
|
|
36
|
-
"@teambit/lanes.modules.diff": "0.0.
|
|
37
|
-
"@teambit/legacy-bit-id": "0.0.
|
|
38
|
-
"@teambit/merging": "0.0.
|
|
22
|
+
"@teambit/lane-id": "0.0.181",
|
|
23
|
+
"@teambit/scope": "0.0.990",
|
|
24
|
+
"@teambit/lanes.ui.models.lanes-model": "0.0.89",
|
|
25
|
+
"@teambit/cli": "0.0.664",
|
|
26
|
+
"@teambit/workspace": "0.0.990",
|
|
27
|
+
"@teambit/express": "0.0.762",
|
|
28
|
+
"@teambit/logger": "0.0.757",
|
|
29
|
+
"@teambit/graphql": "0.0.990",
|
|
30
|
+
"@teambit/component-compare": "0.0.238",
|
|
31
|
+
"@teambit/component-writer": "0.0.26",
|
|
32
|
+
"@teambit/component": "0.0.990",
|
|
33
|
+
"@teambit/export": "0.0.990",
|
|
34
|
+
"@teambit/importer": "0.0.419",
|
|
35
|
+
"@teambit/lanes.entities.lane-diff": "0.0.26",
|
|
36
|
+
"@teambit/lanes.modules.diff": "0.0.299",
|
|
37
|
+
"@teambit/legacy-bit-id": "0.0.423",
|
|
38
|
+
"@teambit/merging": "0.0.305",
|
|
39
39
|
"@teambit/design.ui.pages.not-found": "0.0.366",
|
|
40
|
-
"@teambit/lanes.hooks.use-lanes": "0.0.
|
|
41
|
-
"@teambit/lanes.hooks.use-viewed-lane-from-url": "0.0.
|
|
42
|
-
"@teambit/lanes.ui.compare.lane-compare-page": "0.0.
|
|
43
|
-
"@teambit/lanes.ui.compare.lane-compare": "0.0.
|
|
44
|
-
"@teambit/lanes.ui.lane-overview": "0.0.
|
|
40
|
+
"@teambit/lanes.hooks.use-lanes": "0.0.127",
|
|
41
|
+
"@teambit/lanes.hooks.use-viewed-lane-from-url": "0.0.89",
|
|
42
|
+
"@teambit/lanes.ui.compare.lane-compare-page": "0.0.26",
|
|
43
|
+
"@teambit/lanes.ui.compare.lane-compare": "0.0.45",
|
|
44
|
+
"@teambit/lanes.ui.lane-overview": "0.0.90",
|
|
45
45
|
"@teambit/lanes.ui.menus.lanes-overview-menu": "0.0.5",
|
|
46
|
-
"@teambit/lanes.ui.menus.use-lanes-menu": "0.0.
|
|
47
|
-
"@teambit/lanes.ui.navigation.lane-switcher": "0.0.
|
|
46
|
+
"@teambit/lanes.ui.menus.use-lanes-menu": "0.0.89",
|
|
47
|
+
"@teambit/lanes.ui.navigation.lane-switcher": "0.0.89",
|
|
48
48
|
"@teambit/ui-foundation.ui.menu": "0.0.497",
|
|
49
49
|
"@teambit/ui-foundation.ui.react-router.slot-router": "0.0.501",
|
|
50
|
-
"@teambit/ui": "0.0.
|
|
50
|
+
"@teambit/ui": "0.0.990"
|
|
51
51
|
},
|
|
52
52
|
"devDependencies": {
|
|
53
53
|
"@types/react": "^17.0.8",
|
|
@@ -59,14 +59,14 @@
|
|
|
59
59
|
"@types/react-dom": "^17.0.5",
|
|
60
60
|
"@types/jest": "^26.0.0",
|
|
61
61
|
"@types/testing-library__jest-dom": "5.9.5",
|
|
62
|
-
"@teambit/component.testing.mock-components": "0.0.
|
|
63
|
-
"@teambit/harmony.testing.load-aspect": "0.0.
|
|
64
|
-
"@teambit/snapping": "0.0.
|
|
62
|
+
"@teambit/component.testing.mock-components": "0.0.28",
|
|
63
|
+
"@teambit/harmony.testing.load-aspect": "0.0.27",
|
|
64
|
+
"@teambit/snapping": "0.0.305",
|
|
65
65
|
"@teambit/workspace.testing.mock-workspace": "0.0.14"
|
|
66
66
|
},
|
|
67
67
|
"peerDependencies": {
|
|
68
68
|
"react-router-dom": "^6.0.0",
|
|
69
|
-
"@teambit/legacy": "1.0.
|
|
69
|
+
"@teambit/legacy": "1.0.445",
|
|
70
70
|
"react": "^16.8.0 || ^17.0.0",
|
|
71
71
|
"react-dom": "^16.8.0 || ^17.0.0"
|
|
72
72
|
},
|
|
Binary file
|