feat: symlink core aspects from a symlink that points to the current Bit CLI #7696
Conversation
This file contains 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
zkochan
force-pushed
the
bit-link
branch
2 times, most recently
from
b0003b4 to
cf80a21
Compare
…7700) Otherwise, the components might get created before the envs, and then when loading them, bit throws an error about missing components.
…rge (#7698) ## Proposed Changes - in case the last merge deleted components from the workspace (was soft-removed by the other lane), the abort-merge rewrites it back. - catch checkout errors during "bit lane merge-abort" and explain in the output the status. suggest to run "bit checkout reset" after fixing the error.
…7705) It should not happen, but if it does, throw an error saying that a dependency is not part of the current lane (or main).
…dencies are in place (#7707)
…ar (#7711) It's unclear why `useFsEvents: false,` was used. Removing this fixes the CPU load issue on big projects.
When a component is previously recovered, it has a prop "removed: false" in the model, and then if this component is removed again, it has in .bitmap "removed: true" of the same aspect `teambit.component/remove`. Normally, .bitmap is strongest and it should show the component as removed. However, due to merging of extensions from the legacy ConsumerComponent, this is changed to `removed: false` as the legacy is not aware of .bitmap config data. This PR fixes it by removing the merge of the legacy data as it seems to not be needed. It's possible that it was needed in the past and is not needed anymore.
## Proposed Changes - - -
The trigger for this change is a bug when on a lane and importing a component and snapping, the "onLanesOnly" prop in .bitmap doesn't get added (coz technically it was available on main) , and then when switching to another lane, this component is available unexpectedly. As a result, the next snap could add this component as a dependency of other components in a lane, which is invalid. A lane can't have dependencies in other lanes. Part of this fix is deprecating the `onLanesOnly` property. It's not used anymore to determine which component is available on main. Instead, we check whether a component-object (ModelComponent) has `head`. If it does, we know that this component exist in main and we make it available for you when switching to main even though you didn't use it on main before. (it's kind of trade of, but in many cases, this is the desired behavior regardless, and "bit checkout head" does it already by default). The reason for not removing `onLanesOnly` prop altogether, is to be forward compatible. Otherwise, if users run recent bit version (which strips this prop) and then using old version (which relies on this prop), it will make all components available on main although they exist only on lanes. Another change in this PR is a big refactor of the switch code to reuse the checkout API.
… to suggest solutions (#7728)
…t build --list-tasks" (#7729) This data of the pipelines coming from bit-env command is generated by `BuilderService.getDescriptor()`. One instance generates the data for the three pipelines: build, tag and snap. However, the way how this class was design is to hold one pipeline only. It has a member `taskSlot`, which are the tasks registered to a pipeline. It can be just one. build or snap or tag. Can’t be multiple. What happened is that because only one instance was used, it showed the same build registered tasks for all pipelines. Instead of showing the task lists, it is now showing a message suggesting the users to run `bit build --list-tasks`.
This is related to #7706, one case of onLanesOnly was missing. Added here.
Fixes an issue when scope-renaming multiple components and some of them are envs of others. It was throwing ScopeNotFound. This PR fixes it by replacing the env ids inside `config` prop in the .bitmap file.
## Proposed Changes - enable running snap or tag with both the above flags, as they are unrelated (previously they were coupled) - -
… when isolating components (#7748)
GiladShoham
reviewed
Aug 10, 2023
Comment on lines
29
to
36
| if (currentBitDir) { | ||
| dirPath = resolve(currentBitDir, 'node_modules/@teambit', aspectName); | ||
| if (!existsSync(dirPath)) { | ||
| throw new Error(`unable to find ${aspectName} in ${dirPath}`); | ||
| } | ||
| return dirPath; | ||
| } | ||
|
|
There was a problem hiding this comment.
@zkochan why not just pass the currentBitDir as the second arg to the getAspectDirFromPath below
| @@ -580,6 +585,9 @@ export class DependencyLinker { | |||
|
|
|||
| const packageName = `@teambit/${name}`; | |||
| const target = path.join(rootDir, 'node_modules', packageName); | |||
| if (this._currentBitDir) { | |||
There was a problem hiding this comment.
I wonder if we need to handle this also in some places of load-bit.ts
for example we have there getMainAspect which later used to link the @teambit/bit itself. which I think will now point to the wrong location.
you can also look on linkBit in this file, and see if you get the correct location or not in action.
There was a problem hiding this comment.
yes, you are right. May I just update the getAspectDir to alway prefer reading from currentBitDir? Is there any scenario where currentBitDir should not be used?
There was a problem hiding this comment.
@zkochan yes you can change the getAspectDir
GiladShoham
approved these changes
Nov 2, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Related PR in BVM: teambit/bvm#88
Related fix in pnpm: pnpm/pnpm#6854
new component created: https://bit.cloud/teambit/bvm/path