Bit: Workflow for developing an app + a shared library

[nsams]

When using bit for developing an app + an in-house library using "De-coupling component development from the library" it is not clear to me how the workflow of getting library changes into the central library repository.

In the docs is mentioned the workflow for modifying the library and pulling back the change:
https://docs.bit.dev/tutorial/react-tutorial.html#suggesting-modification-for-component, however for this you develop the library standalone.

In the workflow described here the development happens inside the app but is also tagged from there (and not from a central library repository) https://docs.bit.dev/tutorial/react-app-tutorial.html#tag-a-new-version

[jonisar]

@itaymendel Can you please help understand what exactly is required and how we can help? I think we'll start working on creating a dedicated workflow for this workflow, but in the meantime let's try and solve this one out.

[yairEO]

The consuming app make a change to a component which is, lets say, a part of a repository of components, which are all exported to some bit collection.

So, if a change was made to a consumed component, in the app repo itself and the developer wishes to sync that change and publish, then the developer should bit tag ... the change and then bit export ... it to the remote server.

Then, the developer can switch to the components library repo and bit import all the changes made to any of the components, and it will pull the change to that certain component from the remote server and sync it.

If something wrong happens, try to import that specific component using the override option:

bit import username.foo/bar --override

I hope this answers OP question

[nsams]

Sounds reasonable.

However: doing in the app a bit tag and bit export does immediately release a new version of the library component, a pull request into the library repository (+ extensive code review) will happen afterwards.

How would you avoid that?

[yairEO]

@nsams - why "extensive"? why would "export" cause a pull-request?

It will only happen one you run bit import that triggered local changes.

exporting does not change your code. only tagging, and I wouldn't call it "extensive", and also, if someone changed a component and tagged it, I would say it's important other teams members should know about it.

If no component had been modified but a tag bump had been implemented, then I would say the team should also know about this (via PR) and ask why was it necessary.

[nsams]

We want to develop the library in a central repository where pull requests are created (and the code is reviewed) before releasing (tag+export) the component. Else the pull request is kind of too late, as the change is released (exported) to the bit registry and any user of the library will get the change without being properly reviewed.

[yairEO]

Any developer with permissions can potentially mess up components easily by doing bit export. This is a potential for bugs only if another team member in another app imports the changes and they break the code.

A company with a UI components library that is consumed in several projects, should promote keeping the components in each project in sync with latest version per component. It might not be needed to update a component if there's no real need, but then why do you even need _bit_ in the first place if not to easily maintain sync between isolated components.

since _bit_ doesn't seem to have branches, then if a developer made a change (assuming a code review page is available on bit.dev) and their code changes had been rejected, then they will manually would need to go back to prior version of the component, they must not decide to "rebel" and keep their changes. A developer might be tempted in doing so, saying it's just temporary until the changes will get approved, and after 6 months the developer might find the code too far away from the the others, and unable to sync.

I think there are some problems that should be addressed as company policy, which _bit_ cannot solve, but some it can (somehow) by thinking of a way to make PRs

@itaymendel ?

[itaymendel]

True, at the moment Bit does not have branches or change management for components and their dependency graph. There are internal discussions around how such flow should be implemented. In the very near future, we'll be releasing an RPC before starting the development of it.

At the moment, an automated workflow could work through regular PRs. For example, when a submitted PR is approved, have the CI process trigger an export for the modified components. This way you get a review process and ability to submit modifications.

[dzuncoi]

@itaymendel Any updates on RPC?
I'm looking into this matter at the moment. Since Bit allow developing/modifying components from different repos, it raises a question on how we do PR review if a developer submit their component changes together with his task. And should we maintain a central repo for shared UI components?
Any ideas or suggestions?

[valdestron]

@itaymendel Any updates on RPC?
I'm looking into this matter at the moment. Since Bit allow developing/modifying components from different repos, it raises a question on how we do PR review if a developer submit their component changes together with his task. And should we maintain a central repo for shared UI components?
Any ideas or suggestions?

I know this is old thread, still, we also tried to engineer the workflow with bit.

We come to this where we needed to decide should we do central or multi repos for our components and if so how we will ensure the merge conflicts during exports. We decided to use bit as part of cicd in the components release process using monorepo.

Basically we created two collections prod/staging. Developer can submit a PR to any component in the components monorepo, PR pipeline will make sure that changed components appears in the staging collection with then next version.

Once the PR merged, main pipeline will tag next version and export components to prod collection.

Developer has no control of exporting or tagging components.

[dima716]

@valdestron we are trying to implement something similar that you described in our gitlab ci process. Could you please share how did you make it? As far as understand, once PR is merged, one needs to run bit tag and bit export. Also because the .bitmap file is changed, it's needed to be committed back to the repository, so Bit and repository stay in sync. Is it right?

[GiladShoham]

@dima716 This might be helpful for you -

• https://github.com/teambit/bit-with-azure-devops
• https://github.com/teambit/bit-with-github-actions

[GiladShoham]

@dima716 @valdestron
This also might be useful for you
https://github.com/teambit/bit-with-github-actions