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

Support node recursive module resolution algorithm #43

Closed
ariofrio opened this issue Sep 1, 2018 · 2 comments
Closed

Support node recursive module resolution algorithm #43

ariofrio opened this issue Sep 1, 2018 · 2 comments

Comments

@ariofrio
Copy link
Contributor

ariofrio commented Sep 1, 2018

Currently, cordova-fetch only checks the project's node_module directory, without checking parent directories. For example, in:

myproject/
  node_modules/
    dependency/ -> ../packages/dependency
  packages/
    dependency/
    subproject/
      index.js
      config.xml
      package.json
  package.json

If we require('dependency') from index.js, node will search through all ancestor directories for node_modules/dependency.

However, cordova-fetch doesn't support this. Instead, it will install dependency again (from the npm repository) inside myproject/packages/subproject/node_modules

This is a problem for use cases like yarn workspaces, where the standard node module resolution algorithm is used to help "dependency" be developed alongside "subproject".

Solving this problem could be a good way to improve support for yarn workspaces without needing to add explicit support for yarn.

References:

@raphinesse
Copy link
Contributor

raphinesse commented Sep 1, 2018

Thanks for bringing this to our attention. I think we should indeed try to support the node's full module resolution. Either using the package you linked to or sindresorhus/resolve-from. Frankly I'd prefer the latter, as it actually uses node's implementation.

If the resolved module path does not satisfy the spec, I'd just stop there and continue with installing the requested version. Alternatively we could try searching upwards for the correct version, but I'd rather stick to node's plain module resolution. I can't imagine any use cases that would benefit from doing more than require can do. What do you think?

@ariofrio
Copy link
Contributor Author

ariofrio commented Sep 5, 2018

Yeah, I think that doing what require does, not more or less, is the most useful behavior.

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

2 participants