Escape-Technologies / mookme

Hi,

My project folders in the monorepo sometimes are under 4 levels of directories, and because of that Mookme doesn't find them.

Would it be possible to make maxDepth parameter configurable?

mookme/packages/mookme/src/loaders/hooks-resolver.ts

Line 74 in 54bf776

extractPackagesPaths(depth = 0, maxDepth = 3, source?: string): string[] {

Thank you!

Sure ! It can be configurable, I would leave it as a configuration option (stored in the .mookme.json), and make it default to the current value :)

The recursive search is computationally expensive so I've set a hard limit on this, but I knew the time when I would be asked this would come 😅

If you're willing to contribute, this can be a good first issue, I'll provide a technical strategy asap !

No hush, I actually found a work around by moving the config one layer up so the eslint will apply to all my projects which is also something I had planned. Another solution would be to configure the path(s) where the projects sit in the repository, so that you don’t have to scan too deeply. For example for me the projects are under: • <gitroot>/services/api/subgraph/<service folder> • <gitroot>/services/client So if you let me configure a list of paths of where to find projects then the maxDepth can stay as is. Cheers

…

On Jun 8, 2022, 8:40 AM -0400, Maxence Lecanu ***@***.***>, wrote: If you're willing to contribute, this can be a good first issue, I'll provide a technical strategy asap ! — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

Mookme v1.* worked like this, so it had the advantage you mention (it knows where to look packages for), but it had a few drawbacks:

The initialization was a lot worse than it is right now (there was a very looooooooong prompter-based form to let you enter relatively easily the folders that are supposed to hold the packages). You can try to install and init a project using mookme@1.something to see the difference between 1 & 2 ;)

Also, the behaviour was "configuration" based and not "reality" based which was a bit hard to debug sometimes.

These two are the major reasons that lead me to automatize this part of the execution

Hello @tiagodj !

I will leave this issue stalling, for the reason that I will implement the matching using glob-pattern matching. It will have the benefits that I don't have an algorithm to maintain for this, will work exponentially faster, and will be very unsensitive to the search depth.

I expect this change to solve your issue.

Make maxDepth configurable