FR: Support for monorepos within subdirectory? about qnm HOT 15 CLOSED

Yes, This case still needs to be addressed. Reopening

from qnm.

Nice! Works like a charm!

from qnm.

@mikestopcontinues thanks for you patience and help with this!

from qnm.

Hey @mikestopcontinues, thanks for opening an issue!

Today qnm uses pkg-dir in order to find the nearest package.json so if you run qnm from a direction within src you'll find the nearest node_modules when traversing up the tree.

For the case of a monorepo, if you'll run qnm within one of the packages of the monorepo it will only show you the node_modules of that particular sub modules (e.g. it will ignore the root).

It sounds similar to what you describe. Can you give an example for how you would like it to work? (a way to reproduce the case and what is the expected result)

from qnm.

The snag I'm hitting is that all my node_modules are hoisted, so when I'm within a package dir, qnm throws an error.

First thought: In the event of a package.json but no node_modules, offer a pretty error that explains the situation.

I'm not sure what the optimal logic should be otherwise, if this situation is handled at all. Given there's only a few monorepo formats out there, maybe the right call is an -m, --monorepo arg that looks upward for the telltale signs of a monorepo root?

Here's where things go wrong for me:

monorepo/
  package.json // {"workspaces": ["apps/*"]}
  node_modules/
  apps/
    editor/
      package.json // and no node_modules

I spend most of my time in /editor, but I want to introspect /monorepo.

from qnm.

That's a very good point!

So the use case is that you're running qnm from an inner package within a monorepo.

Possible intents:

1. You want to see this particular package within the monorepo.
2. You want to see modules even if they are hoisted to the root of the monorepo

Since qnm doesn't know the intent of the user one option is to request an option, but I believe that many devs would benefit from qnm's addressing both use cases.

I would like to explore an option in which qnm recognizes that it's within a monorepo and checks hoisted modules in the root. It's important that qnm's UI will show that those modules are within the root and not within the package.

While in your cases the node_modules directory is empty I believe it may be valuable to search through the root node_modules even if it's not but the module isn't exist. I'm also debating whether it's interesting to see if there is a module which is hoisted to the root, possible in a different version.

@mikestopcontinues what are your thoughts on this?

from qnm.

Hey @ranyitz,

I'm very much in favor of qnm automatically inferring the context and just showing everything (with annotations). That's exactly what I'm looking for given the context. Even with hoisting, there's circumstances where you can end up with local node_modules, so I would definitely want to know if one popped up.

Regarding a different package versions, I think there's a few useful cases:

1. Your case, different root vs local, which implies the wrong package is being used or an incomplete upgrade. Definitely useful.
2. Different across the dependency tree for this local package, which suggests an opportunity to optimize. E.G. @mono/A -> (@mono/B, @npm/C@1), @mono/B -> (@npm/C@2)
3. Lastly, different across the entire monorepo root/local node_modules. Does qnm already do this? (Without local node_modules I can't easily tell.) You'd really only want to see it in root, but it'll expand the eagle-eye view qnm already offers.

Anyway, I hope I was able to offer some more context, and thanks again!

from qnm.

Thanks @mikestopcontinues

In that case, let me suggest a solution.
What if we'll show the qnm output like you would run it from the root. The only difference is that we'll mark the current package in some way that would be clear to the user it's the current working directory.

What do you think?

from qnm.

@mikestopcontinues please try v2.8.0 and let me know whether the fixes of #105 solve this issue. If not, feel free to re-open this issue.

from qnm.

@ranyitz I think the PR will be a great solution. The only sticking point is that I'm still getting the could not find node_modules directory error while in a sub-package. No special localized view is totally ok, but I'd still like to be able to run qnm from where I'm working.

from qnm.

@mikestopcontinues Please check 2.9.0. It should support the use-case of an empty node_modules directory within a monorepo.

from qnm.

Hey, something is still amiss.

Here's my tree:

/repo
 - node_modules
 - package.json {"workspaces": ["libs/*"]}
 - /libs
   - /arc-model
     - package.json

What other info can I send your way?

from qnm.

@mikestopcontinues oh, I forgot to fix the fuzzy search mode. I'll push a fix soon.

from qnm.

@ranyitz Thanks!

from qnm.

@mikestopcontinues This should be fixed on v2.9.2 (#112)

from qnm.