Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Add support ignoring parent node_modules for monorepos? #73

Open
MaxmaxmaximusGitHub opened this issue May 25, 2020 · 6 comments

Comments

@MaxmaxmaximusGitHub
Copy link

Add support ignoring parent node_modules for monorepos?

@MaxmaxmaximusGitHub
Copy link
Author

MaxmaxmaximusGitHub commented May 26, 2020

like this

utils.js:

exports.getModulesNamesFromDirLocal = function getModulesNamesFromDirLocal(dir) {
  return exports.readDir(path.resolve(dir, './node_modules')).filter(x => {
    return !exports.contains(['.bin'], x)
  })
}


exports.getModulesNamesFromDir = function getModulesNamesFromDir(dir) {
  const allFoundModules = []
  const pathParts = dir.split(path.sep)

  for (let i = pathParts.length - 1; i >= 0; i--) {
    const parentDirs = pathParts.slice(0, i)
    const parentPath = parentDirs.join(path.sep)
    const foundModules = exports.getModulesNamesFromDirLocal(parentPath)
    allFoundModules.push(...foundModules)
  }

  return allFoundModules
}

@liady
Copy link
Owner

liady commented Jul 8, 2020

In version 2 you can pass additionalModuleDirs to options. Do you think this functionality (looking up the tree) is still needed?

@MaxmaxmaximusGitHub
Copy link
Author

MaxmaxmaximusGitHub commented Aug 3, 2020

@liady this functionality should work by default since node_modules has tree-floating semantics.

@aprilandjan
Copy link

@liady Yeah this is definitely needed when using yarn workspace or lerna, it will be good if it matches with current module resolving strategies.

@akomm
Copy link

akomm commented May 10, 2021

In version 2 you can pass additionalModuleDirs to options. Do you think this functionality (looking up the tree) is still needed?

Yes its needed. Why should a package explicitly point to a directory, which is out of responsibility of this package? (node_modules in monorepo root for example).

@Kadeluxe
Copy link

Maybe it could be an option such as scanParents or something like this. Although personally I'm OK with additionalModuleDirs because in my monorepo projects I have project-specific build setups anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants