Working Student, Creative Cloud Platform and Ecosystem Team @ Adobe; I do many things. Among them developing websites and plugins for Adobe products, primarily Adobe XD. Viva la Open-Source!
Location
Würzburg, Germany
Work
Working Student @ CC Platfrom & Ecosystem Team, Adobe. Student. Adobe XD Plugin Guru
For nx.dev: I had looked into it, but decided against it. While nx looks really cool, it felt like that weird combination of having "too little" (the tool is pretty opinionated about how everything should be structured, e.g., with the --publishable flag and how essentially the entire repo is then controlled by nx) and "too many" (skimming through their documentation didn't really give me an overview of everything nx could do) options at the same time.
Based on that, I think nx is (probably; I haven't tried it 😉) a great solution for a big internal project with an engineering team onboarded onto the project. My use case is an open-source project (i.e., contributors who don't have in-depth knowledge about all the build tools), which is why I decided against it. I didn't feel like I would have been able to write a comprehensive enough, yet short CONTRIBUTING.md if I had used that.
Also, I actively dislike tools where I have no clue what's going on. I'm sure it's possible to learn nx enough to understand what's happening. But not in the amount of time I currently have available for that 😜
For Turborepo: This definitely looks cool. While I had taken a quick look at it, I didn't really look into it in detail (as I had already found the solution presented in the article and was happy with it).
Personally, I tend to dislike tools trying to "solve everything" (I've seen too many tools trying to solve everything and then being unable to handle the complexity of that). While turborepo seems to be a bit better in this regard, the fact that their Getting started section shows building a "pipeline" with building, testing, and linting was what turned me off when I initially looked into it. This is just personal preference, though.
Overall, I would say that I looked at (but not deeply into) both of them but (for my use case) they felt like they tried to solve too much for my taste. Don't get me wrong: I think both of these tools are great and have their advantages, but especially with nx, I feel like it doesn't really work in an environment with a lot of inexperienced contributors. And with turborepo, I haven't (yet 😉) found a need for it in my project. Maybe that day will come. But until then, I prefer to keep my tech stack for something as elementary as "Repo Management" / "building stuff" as small as possible (giving me a better chance of stuff not breaking and the ability to better understand what's going on if something breaks).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for your comment!
For nx.dev: I had looked into it, but decided against it. While nx looks really cool, it felt like that weird combination of having "too little" (the tool is pretty opinionated about how everything should be structured, e.g., with the
--publishableflag and how essentially the entire repo is then controlled by nx) and "too many" (skimming through their documentation didn't really give me an overview of everything nx could do) options at the same time.Based on that, I think nx is (probably; I haven't tried it 😉) a great solution for a big internal project with an engineering team onboarded onto the project. My use case is an open-source project (i.e., contributors who don't have in-depth knowledge about all the build tools), which is why I decided against it. I didn't feel like I would have been able to write a comprehensive enough, yet short
CONTRIBUTING.mdif I had used that.Also, I actively dislike tools where I have no clue what's going on. I'm sure it's possible to learn nx enough to understand what's happening. But not in the amount of time I currently have available for that 😜
For Turborepo: This definitely looks cool. While I had taken a quick look at it, I didn't really look into it in detail (as I had already found the solution presented in the article and was happy with it).
Personally, I tend to dislike tools trying to "solve everything" (I've seen too many tools trying to solve everything and then being unable to handle the complexity of that). While
turboreposeems to be a bit better in this regard, the fact that their Getting started section shows building a "pipeline" with building, testing, and linting was what turned me off when I initially looked into it. This is just personal preference, though.Overall, I would say that I looked at (but not deeply into) both of them but (for my use case) they felt like they tried to solve too much for my taste. Don't get me wrong: I think both of these tools are great and have their advantages, but especially with nx, I feel like it doesn't really work in an environment with a lot of inexperienced contributors. And with turborepo, I haven't (yet 😉) found a need for it in my project. Maybe that day will come. But until then, I prefer to keep my tech stack for something as elementary as "Repo Management" / "building stuff" as small as possible (giving me a better chance of stuff not breaking and the ability to better understand what's going on if something breaks).