Bit: Local and remote automatic tagging with bit components that depend on other bit components

[drewdecarme]

I have a general question around how bit handles automatic tagging of components that aren't imported into the solution that you're working in. I took a few hundred looks over the documentation, but couldn't find the answer to my question so I figured I'd ask it here.

Let's say I have a <List /> component that is composed of a bit <Paragraph /> component and let's say that I have both of them in my project (listed in my .bitmap). I export my <List /> component to bit and it lists my <Paragraph /> component as a dependency.

Let's then say that I update my <Paragraph /> component and then tag it; bit recognizes that change locally and then automatically tags the <List /> component to then be staged for export. That's awesome and I love it. Couldn't be happier about that functionality.

But let's say that my <List /> component isn't in my .bitmap and I make that exact same change on my <Paragraph /> component and tag it. Bit recognizes that change and but it doesn't indicate that the <List /> component also needs to be tagged as well (probably because it's not imported); so all I'm doing is just tagging an incrementing my <Paragraph /> component.

My question is... what happens under the hood in the scenario that I just presented?

• Does bit automatically handle the tagging of the components in the background?
• Do I have to import the <List /> component and then update it myself?
• Is there something that goes on in the internals of bit that handles this update for me?
• If I do have to do this myself, what would the workflow be for doing this?

Any guidance on this would be greatly appreciated

[davidfirst]

Hi @drewdecarme ,
You got it right. Only when the dependent (List in your case) exists locally, Bit knows to auto-tag it. Otherwise, Bit CLI doesn't know about it.

About your questions:

• "Does bit automatically handle the tagging of the components in the background?"
  Practically, Bit searches for all dependents of the currently tagged component and update their dependencies. Bit doesn't go to the remote to search for other dependents.

• "Do I have to import the component and then update it myself?"
  Yes. Currently, if you would like to update List to have the latest Paragraph version, you have to import it to the same project of Paragraph.

• "Is there something that goes on in the internals of bit that handles this update for me?"
  I guess it was answered before. Please let me know if not.

• "If I do have to do this myself, what would the workflow be for doing this?"
  Exactly what you did. Import List and then tag it.

Note that, we had a plan to search for all known dependents we have on the server and provide the user with the options to update them all from the website. I'm unsure what's the status of this plan and what's the priority. Theoretically, it's possible to implement and not too complicated.

[itaymendel]

(I'd like to extend on @davidfirst 's comment)

Updating an entire remote dependency tree is something that Bit will be capable of. We plan on introducing it in stages.
The first stage is to let you handle it locally. By adding a capability to fetch all dependents of a component from a remote collection to your workspace. Then Bit points them to their updated dependencies, so you can run build/test and tag a new version for them, with the updated dependency.

Afterward, we want to extend and automate it, so you can remotely update the component with a new version of a dependency.

As for the availability of this workflow - right now the top priority for Bit is to introduce an improved extension system. Alongside the extension system, we plan on implementing some of the workflows we've been using internally, such as this. This is one of them, and a high priority one at that.

[drewdecarme]

This is all super helpful information! It's great to hear that it's on the roadmap. It was one of the things that I was scratching my head about when thinking of how our team was going to fully adopt using Bit across 7 different enterprise applications.

I'm essentially having my team adopt an atomic design/component system and we're shipping everything (all of our dependency management) off to Bit. We're going to have roughly 5 to 7 layers (at our most complex) of components composing each other, so that's why it was pretty essential that I figure out how that process worked under the hood.

Naturally, I wouldn't want my team to import all of the components for each project just to be able to update one. I'd like to allow them to import what they need, make those updates and have those changes reconcile across components automatically, regardless if it's dependents we're included on the local scope or not.

For now, judging from what you guys have said, I'm going to require that we work in a mono-repo that has all of our components imported so that way we can take advantage of the "automatic local tagging" that Bit provides; no need to always worry about if you have everything on the local scope. I think this way would allow us to scale without having to worry too much.

That is... if you guys don't have a better suggestion

[itaymendel]

I think that you can keep the basic approach right now and enjoy the local-auto-tag mechanism. It does not change the development workflow fundamentally, so it's easier to onboard developers.
Eventually, you can extend your workflow with the introduction of newer flows and features.

[drewdecarme]

Thanks so much for the clarification! The information you guys provides is really helping me better craft our strategy.