Completely lost by the documentation

[paulsimongb]

I have a React Front End connecting to two back end Node JS Servers, all running on TypeScript. I want to be able to share Types and common code such as validation between the three different project folders.

I have already been down the route of trying links outside of project folder with long ../../../ etc paths. However, if I want to use CI/CD that is not going to work as the project is going to be missing the files that are outside of its folder. Then we are in to the mono-repo issue. I also tried symbolic links but that means that I need to run npm installs every time I change code and it still gives problems with CI/CD.

I found a link to bit from an article written on the problems of sharing code between different projects. It seemed that bit might be the answer, however, I have been trying to get bit to work for two days but unfortunately I have got no where. I am not entirely sure what it is supposed to do when it is working.

What I think what bit is meant to do is to allow me to do is to incorporate the same file into different projects and to be able to edit that file in any one of these projects and have the changes propagate to all the other projects. However, I am not clear on whether bit does that and if so how I get it to do that?

I have tried following the documentation but nothing seems to work. Some of the documentation seems to be aimed at a server running on localhost and other documentation expects a remote server. I have signed up for both but just get one error after another.

I am on the point of giving up on bit and will just use a DOS Batch file to copy the files from one project to the others. At least I know that will work, although I have to remember to only edit the code in one project.

I thought I would take the time to say that the documentation needs improvement. There needs to be a much clearer explanation of what bit actually does when it is working and a series of steps to get this working, for a simple localhost case, and after for the step to migrate to a shared server. The current documentation is either too simple or too complex with nothing in between.

[NitsanCohen770]

Hello there,

First and foremost, I deeply empathize with your frustrations. When adopting new technologies or workflows, the initial learning curve can be daunting, especially when the paradigm shift is as significant as transitioning from monolithic structures to component-based engineering.

1. The Bit Mindset: Traditional monolithic projects tend to be viewed as singular, complete units. With Bit, this perspective shifts from projects to scopes. This is why we never do relative imports like ../../../ but instead, opt for absolute imports from node_modules, such as @teambit/design. In Bit's world, scopes are the primary units. A scope provides services to others, and while some scopes can offer a full-fledged app (or what's traditionally known as a "project"), most times they act as consumers of services provided by other scopes. So, it's like a mesh of interdependent micro-projects or components. This decentralization is precisely what gives Bit its power but also what can make it seem unfamiliar at first.

2. Component-Based Software Engineering: Embracing Bit means altering your perspective on software development. It's not just about reusing code; it's about thinking of software as a collection of standalone components that can seamlessly integrate with each other. This change in thinking unlocks flexibility, scalability, and maintainability. Learn more about CBSE.

3. Shared Types and Your Objective: I remember creating a video and even presenting a talk on the exact topic you're facing: shared types. If you're still leaning towards a monolithic project structure, the solution is straightforward. Create a type component, like this entity component example, that exports the required type. Ideally, this should be an entity class, so you can share methods across the front-end and back-end. Once you've set up the type component, you can then install it as a package across your projects and update it as necessary. It's essential to remember here: Bit is not primarily a package manager. While Bit components can be shared as npm packages, it's just one part of the broader Bit ecosystem. The real power of Bit lies in its dependency handling and the propagation of component changes across projects — or hmm, no projects in Bit, sorry — components! (Even for me, it's still hard to shift.)

4. Propagating Changes: Bit excels in managing dependencies and ensuring changes in one component can automatically reflect across all dependent components. I recommend checking out our Ripple CI example to understand how components propagate changes seamlessly.

5. Gradual Integration: Adopting Bit doesn't necessitate a complete overhaul of your existing systems. Like most tools, you can integrate it step by step, becoming familiar with its capabilities at your own pace. You can initiate with types, progress to actual node components, then to React Bit components, and eventually even transform your app into a Bit component. Here's a quickstart guide for further reading.

Lastly, we're genuinely grateful for your feedback. Documentation is crucial for any tool, and we're continuously striving to make it more user-friendly and informative. Our current documentation is predominantly oriented towards guiding users on building a project from Bit components from scratch, which is why our quickstart also has an app component you can run/build/deploy. As a side note, the deployment process is also facilitated by a Bit component, like the Netlify deployer — isn't that awesome? You can use the same deployment logic across projects... hmm, I mean Bit component apps! 😉

Your insights will certainly guide us in refining it further. Should you have any more questions or need specific guidance, please don't hesitate to reach out.

Warm regards,
Nitsan
Bit Docs Maintainer and Builder

[paulsimongb]

Hi Nitsan Thanks for taking the time to reply. I am already pretty familiar with component-based development. My problem is not the concept of that. I have already looked at a lot of the items on the bit web site and some of the specific links in your email. However, I still cannot see how bit answers this or what bit actually does. The React example in getting started seems to be a very noddy Hello World and doesn’t seem to involve sharing any components with a back end, so it has left me none the wiser. I have never heard of netlify so whether it is awesome or not I couldn’t comment. I re-factored my project last night to remove bit and put in the required shared code. I will propagate changes using DOS that I know works. It is not ideal but neither is spending two days on bit when no new features have been added to the system. You can mark this ticket as closed. I just wanted to report the issue I found with the documentation. Obviously, some people have got bit to work, but perhaps they have more time and experience with javascript than I do. Regards Paul From: Nitsan Cohen ***@***.***> Sent: Tuesday, September 5, 2023 11:20 PM To: teambit/bit ***@***.***> Cc: Paul SImon ***@***.***>; Author ***@***.***> Subject: Re: [teambit/bit] Completely lost by the documentation (Issue #7872) Hello there, First and foremost, I deeply empathize with your frustrations. When adopting new technologies or workflows, the initial learning curve can be daunting, especially when the paradigm shift is as significant as transitioning from monolithic structures to component-based engineering. 1. The Bit Mindset: Traditional monolithic projects tend to be viewed as singular, complete units. With Bit, this perspective shifts from projects to scopes. This is why we never do relative imports like ../../../ but instead, opt for absolute imports from node_modules, such as @teambit/design. In Bit's world, scopes are the primary units. A scope provides services to others, and while some scopes can offer a full-fledged app (or what's traditionally known as a "project"), most times they act as consumers of services provided by other scopes. So, it's like a mesh of interdependent micro-projects or components. This decentralization is precisely what gives Bit its power but also what can make it seem unfamiliar at first. 2. Component-Based Software Engineering: Embracing Bit means altering your perspective on software development. It's not just about reusing code; it's about thinking of software as a collection of standalone components that can seamlessly integrate with each other. This change in thinking unlocks flexibility, scalability, and maintainability. Learn more about CBSE<https://en.wikipedia.org/wiki/Component-based_software_engineering>. 3. Shared Types and Your Objective: I remember creating a video<https://www.youtube.com/watch?v=N40sk_7sngQ> and even presenting a talk on the exact topic you're facing: shared types. If you're still leaning towards a monolithic project structure, the solution is straightforward. Create a type component, like this entity component example<https://bit.cloud/teambit/discovery/entities/suggestion>, that exports the required type. Ideally, this should be an entity class, so you can share methods across the front-end and back-end. Once you've set up the type component, you can then install it as a package across your projects and update it as necessary. It's essential to remember here: Bit is not primarily a package manager. While Bit components can be shared as npm packages, it's just one part of the broader Bit ecosystem. The real power of Bit lies in its dependency handling and the propagation of component changes across projects — or hmm, no projects in Bit, sorry — components! (Even for me, it's still hard to shift.) 4. Propagating Changes: Bit excels in managing dependencies and ensuring changes in one component can automatically reflect across all dependent components. I recommend checking out our Ripple CI example<https://bit.cloud/ripple-ci/job/teambit-fix-test-and-custom-env> to understand how components propagate changes seamlessly. 5. Gradual Integration: Adopting Bit doesn't necessitate a complete overhaul of your existing systems. Like most tools, you can integrate it step by step, becoming familiar with its capabilities at your own pace. You can initiate with types, progress to actual node components, then to React Bit components, and eventually even transform your app into a Bit component. Here's a quickstart guide for further reading<https://bit.dev/docs/quick-start/hello-world>. Lastly, we're genuinely grateful for your feedback. Documentation is crucial for any tool, and we're continuously striving to make it more user-friendly and informative. Our current documentation is predominantly oriented towards guiding users on building a project from Bit components from scratch, which is why our quickstart also has an app component you can run/build/deploy. As a side note, the deployment process is also facilitated by a Bit component, like the Netlify deployer<https://bit.cloud/teambit/cloud-providers/deployers/netlify/> — isn't that awesome? You can use the same deployment logic across projects... hmm, I mean Bit component apps! 😉 Your insights will certainly guide us in refining it further. Should you have any more questions or need specific guidance, please don't hesitate to reach out. Warm regards, Nitsan Bit Docs Maintainer and Builder — Reply to this email directly, view it on GitHub<#7872 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AGHWSVXZGYGPHCY24FEQASTXY6QQ5ANCNFSM6AAAAAA4MJFE2U>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[NitsanCohen770]

Hi Paul,

First and foremost, I genuinely understand your perspective. It can sometimes be challenging to comprehend the intricacies of new technologies, especially when they propose a paradigm shift in the way we usually approach software development.

Bit is certainly a tool that encompasses a unique vision, and it's absolutely okay if it doesn’t fit into everyone’s current workflow. Perhaps it will make more sense in the future when you come across different challenges that Bit is designed to tackle.

But as the saying goes, "A picture is worth a thousand words," and we've certainly shared more than a thousand words in this thread. So, let me illustrate.

This is how we construct bit.dev, our documentation site, on Ripple. As you can observe, even a minor modification can have a cascading effect on multiple components. It's this interconnectivity that we envision for the world of software – where every module, every line of code, is interconnected like a vast organism. Just as in nature, where the flutter of a butterfly's wings can cause a typhoon halfway across the world, in Bit's vision, a single change in one component can ripple across the entire software ecosystem.

In the grand scheme of things, we're aspiring for a world where software evolves in tandem, where a single enhancement can elevate countless projects. It's a bit like the human body, where a small change can impact the whole system.

I sincerely hope that one day, when the time feels right for you, you might see the potential in our vision and reconsider integrating Bit into your projects. Until then, I wish you the best in all your endeavors, and I'm here to assist or discuss further anytime you wish.

Warm regards,
Nitsan
Bit Docs Maintainer and Builder

[Thomas-Boi]

@paulsimongb

Just my own two cents, here's how I used Bit to re-use code across projects

• Create a Bit workspace and make my reusable Bit components there
  • I originally tried to set up Bit in my existing React project -> would not recommend
• Once done, export it to Bit's free NPM repo
• Set up Bit Cloud for other members of my team
• Set up my NPM projects (specifically the .npmrc) to recognize Bit Cloud as a NPM server
• Run npm install my-package to install my reusable Bit components as normal NPM packages.

Everything is done via exporting to a remote server then pulling the changes (similar to Bit). Assuming that your front and backend uses Typescript, I think this would work fine for you. If you are confused by the website, perhaps check out their Youtube videos which might be more helpful.

I have used Bit for almost a year now and while it's incredibly painful at times due to the configs, it's worth it. I love the fact that I can reuse my code cleanly with version management. If we ever make another front end, all my components with pre-set stylings can be easily import over.