I'm having a hard time seeing how Turborepo working great on Vercel is relevant to this doc. While true, this documentation is meant for folks migrating from Nx to Turborepo. It doesn't have anything to do with Vercel, nor should it. It's very possible that someone could be getting acquainted with Turborepo for the first time on this document, and this section would be misleading for them.

I don't know how else to read these edits other than a projection about the way Nx has been closing off the open-source parts of its offering, according to what Nx users have been repeatedly telling me. I don't write this to be rude or antagonistic, but I can't tell what these edits are meant to be for and am having to guess.

We take great pride in creating an open-source project that anyone can use how they wish. As fate would have it, this morning we just finished up some improvements for self-hosting (ref and ref) and I've been working on creating an OpenAPI spec viewer for our docs the past week or so.

Were you meaning something else/I'm not getting it?

I'm sorry if it wasn't clear in the video, but in it I tried to relay the following: I am not an expert on Turborepo, and so this was an honest attempt by me to provide additional, objective steelman arguments as to why you might want to switch.

As I demonstrated, some of the existing arguments needed to be removed completely due to their inaccuracy, so I wanted to offer up ideas for replacements that I felt were honest and objective (again with the caveat that I am not deep enough to know all of the potential benefits of Turborepo and they are therefore high level starting points for discussion).

If you disagree with this point and don't want it included that's totally fine, and I'm sure you can come up with other points to replace it (do feel free to commit directly to the branch if you want to).

Vercel famously makes a ton of open-source tooling, so I am not really sure what the link is there with what you're saying and why you thought it was a negative thing, it wasn't intended to be one.

Sounds good! I illustrated how the spirit of those sections should stay here, so let's refocus there.

I've not watched the video in full maybe their an explanation. I love NX and I know nx offer "free license" but I think this section should remain as it's not the same and for Enterprise its a paid license.

Lot of the rest fair just thisnsection removal seems strange

There is an explanation given in the video, but I'm having the hardest time understanding it.

An explicit reason for this section getting written has been an influx of new users to Turborepo, coming from Nx, because of a change in the cost structure of using Nx. They're finding that features that they used to use for free aren't free anymore.

Note that this is specifically not my experience or something I went out of my way to invent. This is written how it is because of experiences other developers have shared with me. The first couple times I heard it, I went to read the docs about how the pricing is meant to work, and was confused by the explanations and documentation given. In one place it would sound like its part of the open-source offering, and the next would sound like it isn't.

I continually pestered the people I was talking to about this, and insisted that maybe they were misunderstanding the documentation (hoping that their familiarity with the tool or Nx team would lead me to concluding that the feature is still free), but they repeated that it was the case that they were losing features.

From the conversations I've had, questions I've answered, and frequency at which this comes up, I don't see any other option than having to mention this paradigm in this documentation.

Ive been extremely vocal around this with NX. Many still feel like the free license not enough and their no way to run remote cache without it being a NX licensed software. I've got a hot patch but once it goes to rust it's nesr impossible

I can see why these changes to start with a JS Workspace would make sense without context. I did it without a Workspace because everyone I've had to help with a migration comes from a place of being misaligned with the JS ecosystem due to the recommendations of the Nx documentation. Without fail, we have to introduce the Workspace first, and then we continue with the rest.

Would you want to take another try at it to make the doc say something to the effect of "If you already are using Workspaces, you can skip steps x, y, and z"? A banner above this code block would likely work great!

I do feel like inflammatory language like "misaligned with the JS ecosystem" isn't particularly helpful to the discourse. I don't think the countless monorepos out there deriving enormous value from the setup that Nx originally started with (before the prevalence of package manager workspaces) deserve such a derogatory label. We still provide support for this/them, in addition to package manager workspaces. You have to remember your sampling bias here, it is exclusively folks who are already dissatisfied that are going through this with you.

I'm not fully picturing what you're proposing but I think it sounds reasonable, maybe I could take a look at the change if you make it please?

What you've quoted is not inflammatory language. I can understand that you might not like it, but it's purely a technical comment. If you told me something in Turborepo isn't aligned with the ecosystem in some way, I would thank you and do my best to fix it. The JS ecosystem has aligned on Workspaces and the majority of the subset of Nx users that come to Turborepo don't use them, to their detriment.

You have to remember your sampling bias here, it is exclusively folks who are already dissatisfied that are going through this with you.

I'm well aware of this. This page's contents are specifically written as a collection of their feedback.

Can you say what tasks or configuration are missing?

Sure yeah, again this is regarding the argument that Nx requires "more configuration" and this felt like it wasn't clearly established as being intentionally not "apples to apples".

Here in Step 7 you have a tasks configuration that only deals with building and serving the Next.js application, whereas the nx.json we start the process with covers building, serving (both from source and from dist), typechecking and linting.

Thank you