Monorepo support

[matheus1lva]

Hello! Does it has support for a mono repo? Scanning through multiple package.json?

[ruyadorno]

hi @playma256 unfortunately ntl does not offer any special support to mono repo structures out of the box right now but rest assured that's something I would love to support!

Thing is I'm not a monorepo person myself and I don't have any projects in my radar using it - that said I would love to hear from the people using it what would make sense for them.

Some questions to start with:

• What are the current projects/ecosystems to support/test for? (thinking lerna, etc)
• How does monorepo structured projects usually structure their tasks?
• Do these projects usually aliases tasks to the top level?
• What features are missing in ntl to make managing monorepos easier?

Let's get this conversation started 🚀

[matheus1lva]

Hello! We have few people that would be interested on it!

What are the current projects/ecosystems to support/test for? (thinking lerna, etc)

Lerna, yarn workspaces

How does monorepo structured projects usually structure their tasks?

Usually they have tasks per package and sometimes they expose those tasks on the root package.json file.

What i mean:

Given we have the package: @test/my-cli with the following commands:

{
	"scripts": {
		"runSomething": "do-it"
	}
}

This could/would be exposed on the top level scripts as (using the yarn workspaces syntax):

...
"runSomething:my-cli": "yarn workspaces @test/my-cli runSomething"
...

Do these projects usually aliases tasks to the top level?

Sometimes they do!

What features are missing in ntl to make managing monorepos easier?

The only thing could be scanning through all the package.json files available inside any folder (excluding node_modules). By gathering all the scripts, everything else works aswell! (i suppose)

There is a monorepo playground we have and you could have a look as well (https://github.com/entria/entria-fullstack)

That can be helpful while developing it! I'll try to find sometime to help with this!

[ruyadorno]

Awesome, that sounds like a great start!

There is a monorepo playground we have and you could have a look as well (https://github.com/entria/entria-fullstack)

👍 this kind of reference is very useful for adding tests

That can be helpful while developing it! I'll try to find sometime to help with this!

Great to hear! Personally I don't think I'll be putting much development time into the project right now so I'll leave this one open for the community to help 😊

[matheus1lva]

FYI: i created a small package which helps finding all package.json files. I'm planning to add this as a helper to this feature!

https://github.com/PlayMa256/find-all-package-files

[mischah]

Hej, this is a great idea.

I’d like to work on this.
Or did you already started @playma256?

---

Just a last Question about the list behavior when finding a monorepo.

Currently we are showing tasks like this:

$ ntl
⬢  Node Task List
? Select a task to run: (Use arrow keys)
❯ tasks
  start
  test
  build
(Move up and down to reveal more choices)

Option 1

In case of a monorepo we could provide a list of sub repos first:

$ ntl
⬢  Node Task List
? Select a repo or the root tasks select a task: (Use arrow keys)
❯ Root tasks
  checkbox
  confirm
  core
  editor
(Move up and down to reveal more choices)

Not sure about the wording though. Anyway: We would present the task list after choosing one.

Option 2

In case of a monorepo we show the root tasks and sub repos in the list:

$ ntl
⬢  Node Task List
? Select a root task to run or choose a sub repo to show their tasks: (Use arrow keys)
❯ bootstrap
  test
  checkbox
  confirm
  core
  editor
(Move up and down to reveal more choices)

Where the sub repos should be formatted other than the tasks (eg. colored and bold).

Any opinions on that?

[mischah]

Another important thing is to think about how the monorepo feature should go along with the --rerun flag 🤔

[matheus1lva]

@mischah i had just started writing down, i wrote literally 2 lines hahaha, you can go ahead and do that!

Let me contribute to the discussions

I personally think that is going to be a better UX if we can have option 2 because there are many scripts that can be run on the root as well like global lint, tests, stuff like that!
Giving a list of scripts per package is the best idea!

[ruyadorno]

ok, I have given this a fair amount of thinking and I would like to avoid as much as possible writing a custom implementation for handling the monorepo discovery logic. I would much prefer reusing some already existing code from one of the big projects, such as lerna project.getPackages():

https://github.com/lerna/lerna/blob/6c4ee5294002c0e464f557b149516017eccf2a07/core/project/index.js#L169-L176

Given that workspaces are a feature in npm's radar for v7 (maybe not v7.0 but def during v7.x life) it could be a very good idea to wait for it to land there before we implement it here (then we could hook to the APIs npm natively exposes) - but to be clear: if someone shows up with a PR and it seems to be something the community wants, I wouldn't mind merging it 😊

[ruyadorno]

Update: The RFC for npm workspaces is out: npm/rfcs#103