@teambit/lanes 0.0.130 → 0.0.131

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.
Files changed (2) hide show
  1. package/lanes.docs.md +80 -0
  2. package/package.json +21 -14
package/lanes.docs.md ADDED
@@ -0,0 +1,80 @@
1
+ See more details about these two features here: [Lanes](https://github.com/teambit/bit/issues/1986). [Snaps](https://github.com/teambit/bit/issues/1985).
2
+
3
+ The following describes the final implementation, which differs from the specification above.
4
+
5
+ ## Synopsis
6
+
7
+ - create a snap: `bit snap` (synopsis similar to the `bit tag`).
8
+ - create a new lane: `bit lane create <name>`
9
+ - list lanes: `bit lane list`.
10
+ - switch between lanes: `bit switch <name>`
11
+ - merge lanes: `bit lane merge`.
12
+ - show lane details: `bit lane show <name>`
13
+ - diff between lanes: `bit lane diff <values>`
14
+ - track local lane to a remote lane: `bit switch --as`
15
+ - remove a lane `bit lane remove <name>`.
16
+ - fetch lane objects (without the components): `bit fetch --lanes`.
17
+ - import a lane: `bit switch <name> --remote`.
18
+ - export current lane: `bit export`.
19
+ - (internal) cat lane object: `bit cat-lane <name>`.
20
+
21
+ ## Remaining tasks
22
+
23
+ - [ ] Remove components from a remote lane.
24
+ - [ ] Bit import with no args. When bitmap has a remote lane, should import the lane.
25
+ - [ ] Tag dependencies to include them in a lane.
26
+ - [ ] Test bit-fetch components
27
+ - [ ] Rename lanes.
28
+ - [ ] Fix performance issue. Now it fetches all parents every time. It doesn't make sense.
29
+ - [ ] Fix performance issue. Now it traverses all parents to see if a hash in there.
30
+
31
+ ## Important points
32
+
33
+ ### Performance consideration
34
+
35
+ Currently, if it imports with no-deps, it doesn't ask for parents, if it imports with deps it imports with all parents. It is originated from src/api/scope/lib/fetch.ts: `const collectParents = !noDependencies;`. We need to make a decision here.
36
+
37
+ ### Model changes
38
+
39
+ - `Version.parents`. This is added only if the lanes feature is enabled. (it doesn't change the hash).
40
+ - `Component.head` This is added only if the lanes feature is enabled. (it doesn't change the hash).
41
+
42
+ ### Hash
43
+
44
+ - Snap's hash is generated by a UUID and then converted into sha1. `sha1(v4())`.
45
+ - Lane's hash is generated by a UUID and then converted into sha1. `sha1(v4())`.
46
+ - Tag's hash stays the same. Generated by the `Version.id()`.
47
+
48
+ ### Lane Data
49
+
50
+ Lane data, for the most cases is a map of component-id:snap-head, in other words, it saves per component the head snap. There are 3 different places where we store such data for different purposes.
51
+
52
+ - `lane-object` "Lane" is saved in the scope `.bit/objects` (.bit can be .git/bit locally), it has a unique hash and contains a map of components and their heads. This object exists on both local and remote scopes. Its main purpose is to sync lane-data between scopes. See `Lane` class (in scope/model) for the implementation details.
53
+ - `workspace-lane` (component and their heads) is saved in `.bit/workspace/lanes/lane-name`. Remote scopes don't have this data. Its main purpose is to store data that exists only locally and does not exist on the remote. See `WorkspaceLane` class for the implementation details.
54
+ - `remote-lane` (component and their heads) is saved in `.bit/refs/remote/remote-name/lane-name`. These refs files are saved in both, local and remote scopes. Its main purpose is to keep track where the remote-heads are per lane. See `RemoteLanes` class for the implementation details.
55
+
56
+ More places that stores lanes related data:
57
+
58
+ - the currently checked out lane is saved in the scope.json file. (e.g. `{ lanes: { current: "lane-a", tracking: "remote/lane-a" } }`).
59
+ - When switching to a remote lane, the .bitmap is updated as well with the remote-name, so then, when cloning the project, it's possible to fetch the remote lane data.
60
+
61
+ Summary of when/what lanes data is saved per command:
62
+
63
+ - `bit lane create`: creates a new lane-object and creates a new lane record in scope.json.
64
+ - `bit snap`: adds an entry to the lane-object and to the workspace-lane.
65
+ - `bit export`: 1) deletes all records from workspace-lane (as they're in sync with the remote). 2) pushes the lane-object to the remote. On the remote, the lane-object is created or updated/merged.
66
+ - `bit switch --remote`: 1) creates/updates lane-object in the scope. 2) creates/updates remote-lane. the remote-lane is updated also for main.
67
+ - `bit fetch` or `bit import --objects`: creates/updates remote-lane. the remote-lane is updated also for main. It doesn't update/merge the lane object.
68
+
69
+ ### Merge during import
70
+
71
+ - When the remote is ahead, it's easy, just update the head to the remote-head.
72
+ - When the local and remote have diverged, it's more complex. We need to create a snap-merge that has two parents, one point to the local head and one point to the remote head.
73
+ - On `bit import --objects` (or `bit fetch`) we don't merge. The remote head is saved in the .bit/refs/remote dir. Then, `bit status` shows that these components are merge-pending.
74
+ - On `bit import <id>` we do the merge.
75
+ - in case the merge wasn't done and the user is trying to export, the remote blocks is as it finds out that its head doesn't exist on the incoming component.
76
+ - in case the snap-merge failed due to a conflict, it saves the conflict and heads data into `.bit/unmerged.json` file.
77
+
78
+ ### Useful APIs
79
+
80
+ - bit-map `getAllIdsAvailableOnLane()` filters the currently checked out lane.
package/package.json CHANGED
@@ -1,12 +1,12 @@
1
1
  {
2
2
  "name": "@teambit/lanes",
3
- "version": "0.0.130",
3
+ "version": "0.0.131",
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.130"
9
+ "version": "0.0.131"
10
10
  },
11
11
  "dependencies": {
12
12
  "chalk": "2.4.2",
@@ -14,12 +14,12 @@
14
14
  "graphql-tag": "2.12.1",
15
15
  "@babel/runtime": "7.12.18",
16
16
  "core-js": "^3.0.0",
17
- "@teambit/bit-error": "0.0.374",
18
- "@teambit/cli": "0.0.388",
19
- "@teambit/scope": "0.0.558",
20
- "@teambit/workspace": "0.0.558",
21
- "@teambit/graphql": "0.0.558",
22
- "@teambit/lanes.modules.diff": "0.0.81"
17
+ "@teambit/bit-error": "0.0.375",
18
+ "@teambit/cli": "0.0.389",
19
+ "@teambit/scope": "0.0.559",
20
+ "@teambit/workspace": "0.0.559",
21
+ "@teambit/graphql": "0.0.559",
22
+ "@teambit/lanes.modules.diff": "0.0.82"
23
23
  },
24
24
  "devDependencies": {
25
25
  "@types/mocha": "5.2.7",
@@ -30,7 +30,7 @@
30
30
  "@types/node": "12.20.4"
31
31
  },
32
32
  "peerDependencies": {
33
- "@teambit/legacy": "1.0.174",
33
+ "@teambit/legacy": "1.0.175",
34
34
  "react-dom": "^16.8.0 || ^17.0.0",
35
35
  "react": "^16.8.0 || ^17.0.0"
36
36
  },
@@ -58,7 +58,7 @@
58
58
  "react": "-"
59
59
  },
60
60
  "peerDependencies": {
61
- "@teambit/legacy": "1.0.174",
61
+ "@teambit/legacy": "1.0.175",
62
62
  "react-dom": "^16.8.0 || ^17.0.0",
63
63
  "react": "^16.8.0 || ^17.0.0"
64
64
  }
@@ -67,10 +67,17 @@
67
67
  "files": [
68
68
  "dist",
69
69
  "!dist/tsconfig.tsbuildinfo",
70
- "README.md",
71
- "README.mdx",
72
- "*.js",
73
- "*.json"
70
+ "**/*.md",
71
+ "**/*.mdx",
72
+ "**/*.js",
73
+ "**/*.json",
74
+ "**/*.sass",
75
+ "**/*.scss",
76
+ "**/*.less",
77
+ "**/*.css",
78
+ "**/*.css",
79
+ "**/*.jpeg",
80
+ "**/*.gif"
74
81
  ],
75
82
  "private": false,
76
83
  "engines": {