vuki656/package-info.nvim

[FEATURE REQUEST] Support monorepo.

ilyaliao opened this issue · 3 comments

Issues

  • I have checked existing issues and there are no existing ones with the same request.

Feature description

Hi there! Thank you for developing such a wonderful package. I really enjoy it.

Currently, it seems to have trouble working on projects with a monorepo architecture.

package-info.mov

截圖 2023-08-12 上午9 25 48

Mainly because in a monorepo, you need to explicitly specify the download location.

Example.

(root)
pnpm add -wD naive-ui

(workspace)
pnpm add (package name) -r --filter

pnpm workspace document

So simply adding it won't suffice for installation; further analysis is required.

Perhaps it could read the pnpm-workspace.yaml to determine which package.json files belong to the workspace and proceed with the downloads?
(I haven't used npm or yarn workspaces before.)

Help

Yes, but I don't know how to start. I would need guidance

Implementation help

No response

I just cloned the project and tried to understand its functionality. I found that the biggest challenges might be:

  • Recording the currently opened package name.
  • Determining whether the current location is the root directory or a subdirectory.

If this plugin only opens when a package.json file is opened, achieving the second point could be quite difficult.
If I understand correctly, could you please confirm? I'm new to Lua programming.

Recording the currently opened package name.
Determining whether the current location is the root directory or a subdirectory.

Hm, not really sure regarding this one since currently, it doesn't know about either. You would have to look at some other plugins that navigate root directories. Maybe lspconfig and plenary.

If this plugin only opens when a package.json file is opened

This was discussed but it was never implemented since it's convenient to run plugin commands from other files.


Regarding reading from config files, it depends on all 3 of the package managers. If it can be done with one and not the other two, I think it's a hard sell. I would prefer a similar/same approach to solve all 3 of them.

hinell commented

@vuki656 The project is usually opened in a workspace root where package.json with packages: ... field might be found. So it's not a big deal to check which package.json was opened relative to the root.