@teambit/config-merger 0.0.176 → 0.0.178

package/artifacts/__bit_junit.xml

@@ -1,4 +1,4 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <testsuites tests="0" failures="0" errors="0" skipped="0">
-  <testsuite name="teambit.workspace/config-merger@0.0.176" tests="0" failures="0" errors="0" skipped="0"/>
+  <testsuite name="teambit.workspace/config-merger@0.0.178" tests="0" failures="0" errors="0" skipped="0"/>
 </testsuites>

package/artifacts/schema.json

@@ -1297,7 +1297,8 @@
               "character": 1
             },
             "raw": "/**\n * perform 3-way merge of component configuration (aspects).\n * normally this is needed when merging one lane into another. the component may have different aspects config in each lane.\n * the baseAspects are the aspects of the component in the diversion point (the common ancestor of the two lanes).\n * the currentAspects are the aspects of the component in the current lane.\n * the otherAspects are the aspects of the component in the other lane. this is the lane we merge into the current lane.\n *\n * the basic merging strategy is a simple comparison between the aspect-configs, if they're different, we have a conflict.\n * we have two special cases:\n *\n * 1. dependency-resolver: we do a deeper check for the policy, we compare each dependency separately. also, we take\n * into account not only the config, but also the data. this is needed because some dependencies are automatically\n * added by Bit (from the import statements in the code) and they're not in the config. the final config has the deps\n * from both sources, the config and the data. The way we know to differentiate between them is by the \"force\" prop.\n * the config has always force: true.\n *\n * 2. envs: if we don't treat it specially, the user will need to make the change not only in the envs aspect, but also\n * in the deps-resolver (because the env is added as a devDependency) and also in the aspect itself (because\n * teambit.envs/env has only the id and not the version). to make it simpler, we ignore the envs in the deps-resolver\n * we ignore the individual aspect that is the env itself. we only show teambit.envs/env and we put the env id and\n * version. later, when the component is loaded, we split the id and the version and put them in the correct places.\n * see workspace.componentExtension / adjustEnvsOnConfigMerge for more details.\n */",
-            "comment": "perform 3-way merge of component configuration (aspects).\nnormally this is needed when merging one lane into another. the component may have different aspects config in each lane.\nthe baseAspects are the aspects of the component in the diversion point (the common ancestor of the two lanes).\nthe currentAspects are the aspects of the component in the current lane.\nthe otherAspects are the aspects of the component in the other lane. this is the lane we merge into the current lane.\n\nthe basic merging strategy is a simple comparison between the aspect-configs, if they're different, we have a conflict.\nwe have two special cases:\n\n1. dependency-resolver: we do a deeper check for the policy, we compare each dependency separately. also, we take\ninto account not only the config, but also the data. this is needed because some dependencies are automatically\nadded by Bit (from the import statements in the code) and they're not in the config. the final config has the deps\nfrom both sources, the config and the data. The way we know to differentiate between them is by the \"force\" prop.\nthe config has always force: true.\n\n2. envs: if we don't treat it specially, the user will need to make the change not only in the envs aspect, but also\nin the deps-resolver (because the env is added as a devDependency) and also in the aspect itself (because\nteambit.envs/env has only the id and not the version). to make it simpler, we ignore the envs in the deps-resolver\nwe ignore the individual aspect that is the env itself. we only show teambit.envs/env and we put the env id and\nversion. later, when the component is loaded, we split the id and the version and put them in the correct places.\nsee workspace.componentExtension / adjustEnvsOnConfigMerge for more details."
+            "comment": "perform 3-way merge of component configuration (aspects).\nnormally this is needed when merging one lane into another. the component may have different aspects config in each lane.\nthe baseAspects are the aspects of the component in the diversion point (the common ancestor of the two lanes).\nthe currentAspects are the aspects of the component in the current lane.\nthe otherAspects are the aspects of the component in the other lane. this is the lane we merge into the current lane.\n\nthe basic merging strategy is a simple comparison between the aspect-configs, if they're different, we have a conflict.\nwe have two special cases:\n\n1. dependency-resolver: we do a deeper check for the policy, we compare each dependency separately. also, we take\ninto account not only the config, but also the data. this is needed because some dependencies are automatically\nadded by Bit (from the import statements in the code) and they're not in the config. the final config has the deps\nfrom both sources, the config and the data. The way we know to differentiate between them is by the \"force\" prop.\nthe config has always force: true.\n\n2. envs: if we don't treat it specially, the user will need to make the change not only in the envs aspect, but also\nin the deps-resolver (because the env is added as a devDependency) and also in the aspect itself (because\nteambit.envs/env has only the id and not the version). to make it simpler, we ignore the envs in the deps-resolver\nwe ignore the individual aspect that is the env itself. we only show teambit.envs/env and we put the env id and\nversion. later, when the component is loaded, we split the id and the version and put them in the correct places.\nsee workspace.componentExtension / adjustEnvsOnConfigMerge for more details.",
+            "tags": []
           },
           "signature": "class ComponentConfigMerger",
           "name": "ComponentConfigMerger",
@@ -3380,7 +3381,8 @@
               "character": 1
             },
             "raw": "/**\n * perform 3-way merge of component configuration (aspects).\n * normally this is needed when merging one lane into another. the component may have different aspects config in each lane.\n * the baseAspects are the aspects of the component in the diversion point (the common ancestor of the two lanes).\n * the currentAspects are the aspects of the component in the current lane.\n * the otherAspects are the aspects of the component in the other lane. this is the lane we merge into the current lane.\n *\n * the basic merging strategy is a simple comparison between the aspect-configs, if they're different, we have a conflict.\n * we have two special cases:\n *\n * 1. dependency-resolver: we do a deeper check for the policy, we compare each dependency separately. also, we take\n * into account not only the config, but also the data. this is needed because some dependencies are automatically\n * added by Bit (from the import statements in the code) and they're not in the config. the final config has the deps\n * from both sources, the config and the data. The way we know to differentiate between them is by the \"force\" prop.\n * the config has always force: true.\n *\n * 2. envs: if we don't treat it specially, the user will need to make the change not only in the envs aspect, but also\n * in the deps-resolver (because the env is added as a devDependency) and also in the aspect itself (because\n * teambit.envs/env has only the id and not the version). to make it simpler, we ignore the envs in the deps-resolver\n * we ignore the individual aspect that is the env itself. we only show teambit.envs/env and we put the env id and\n * version. later, when the component is loaded, we split the id and the version and put them in the correct places.\n * see workspace.componentExtension / adjustEnvsOnConfigMerge for more details.\n */",
-            "comment": "perform 3-way merge of component configuration (aspects).\nnormally this is needed when merging one lane into another. the component may have different aspects config in each lane.\nthe baseAspects are the aspects of the component in the diversion point (the common ancestor of the two lanes).\nthe currentAspects are the aspects of the component in the current lane.\nthe otherAspects are the aspects of the component in the other lane. this is the lane we merge into the current lane.\n\nthe basic merging strategy is a simple comparison between the aspect-configs, if they're different, we have a conflict.\nwe have two special cases:\n\n1. dependency-resolver: we do a deeper check for the policy, we compare each dependency separately. also, we take\ninto account not only the config, but also the data. this is needed because some dependencies are automatically\nadded by Bit (from the import statements in the code) and they're not in the config. the final config has the deps\nfrom both sources, the config and the data. The way we know to differentiate between them is by the \"force\" prop.\nthe config has always force: true.\n\n2. envs: if we don't treat it specially, the user will need to make the change not only in the envs aspect, but also\nin the deps-resolver (because the env is added as a devDependency) and also in the aspect itself (because\nteambit.envs/env has only the id and not the version). to make it simpler, we ignore the envs in the deps-resolver\nwe ignore the individual aspect that is the env itself. we only show teambit.envs/env and we put the env id and\nversion. later, when the component is loaded, we split the id and the version and put them in the correct places.\nsee workspace.componentExtension / adjustEnvsOnConfigMerge for more details."
+            "comment": "perform 3-way merge of component configuration (aspects).\nnormally this is needed when merging one lane into another. the component may have different aspects config in each lane.\nthe baseAspects are the aspects of the component in the diversion point (the common ancestor of the two lanes).\nthe currentAspects are the aspects of the component in the current lane.\nthe otherAspects are the aspects of the component in the other lane. this is the lane we merge into the current lane.\n\nthe basic merging strategy is a simple comparison between the aspect-configs, if they're different, we have a conflict.\nwe have two special cases:\n\n1. dependency-resolver: we do a deeper check for the policy, we compare each dependency separately. also, we take\ninto account not only the config, but also the data. this is needed because some dependencies are automatically\nadded by Bit (from the import statements in the code) and they're not in the config. the final config has the deps\nfrom both sources, the config and the data. The way we know to differentiate between them is by the \"force\" prop.\nthe config has always force: true.\n\n2. envs: if we don't treat it specially, the user will need to make the change not only in the envs aspect, but also\nin the deps-resolver (because the env is added as a devDependency) and also in the aspect itself (because\nteambit.envs/env has only the id and not the version). to make it simpler, we ignore the envs in the deps-resolver\nwe ignore the individual aspect that is the env itself. we only show teambit.envs/env and we put the env id and\nversion. later, when the component is loaded, we split the id and the version and put them in the correct places.\nsee workspace.componentExtension / adjustEnvsOnConfigMerge for more details.",
+            "tags": []
           },
           "signature": "class ComponentConfigMerger",
           "name": "ComponentConfigMerger",
@@ -4088,7 +4090,7 @@
   "componentId": {
     "scope": "teambit.workspace",
     "name": "config-merger",
-    "version": "0.0.176"
+    "version": "0.0.178"
   },
   "taggedModuleExports": []
 }

package/package.json

@@ -1,12 +1,12 @@
 {
   "name": "@teambit/config-merger",
-  "version": "0.0.176",
+  "version": "0.0.178",
   "homepage": "https://bit.cloud/teambit/workspace/config-merger",
   "main": "dist/index.js",
   "componentId": {
     "scope": "teambit.workspace",
     "name": "config-merger",
-    "version": "0.0.176"
+    "version": "0.0.178"
   },
   "dependencies": {
     "lodash": "4.17.21",
@@ -17,14 +17,14 @@
     "@teambit/component-version": "1.0.3",
     "@teambit/harmony": "0.4.6",
     "@teambit/bit-error": "0.0.404",
-    "@teambit/builder": "1.0.309",
-    "@teambit/dependency-resolver": "1.0.309",
-    "@teambit/envs": "1.0.309",
-    "@teambit/logger": "0.0.979",
-    "@teambit/cli": "0.0.886",
+    "@teambit/builder": "1.0.311",
+    "@teambit/dependency-resolver": "1.0.311",
+    "@teambit/envs": "1.0.311",
+    "@teambit/logger": "0.0.981",
+    "@teambit/cli": "0.0.888",
     "@teambit/component-package-version": "0.0.433",
-    "@teambit/config": "0.0.1060",
-    "@teambit/workspace": "1.0.309"
+    "@teambit/config": "0.0.1062",
+    "@teambit/workspace": "1.0.311"
   },
   "devDependencies": {
     "@types/lodash": "4.14.165",
@@ -35,7 +35,7 @@
     "@teambit/harmony.envs.core-aspect-env": "0.0.39"
   },
   "peerDependencies": {
-    "@teambit/legacy": "1.0.711"
+    "@teambit/legacy": "1.0.713"
   },
   "license": "Apache-2.0",
   "optionalDependencies": {},