Confusing behaviour when having nested package.json

[janpaul123]

I struggled with setting up import-js for a repo that had (mistakenly) two package.json files. This was the directory structure:

- import.js
- package.json
- client/
  - package.json
  - components/
    - some_file.js

I was trying to figure out why some_file.js was not picking up the configuration. So I tried to set minimumVersion to something large, but then it errored out. So it looked like it was picking up the configuration. But then I tried to use other config options, but it wouldn't pick them up.

The reason for this is that in this case Configuration is initialised multiple times but with different workingDirectory params. The first time it is initialised correctly, but the second and third time the working directory was pointing at the client/ directory.

This was particularly confusing since there was no error message and it even seemed like configuration was somewhat picked up (because of the minimumVersion thing working properly).

[trotzig]

The code that finds the project root is pretty naive, it simply looks for a package.json file:

import-js/lib/findProjectRoot.js

Line 13 in 01e6569

if (fs.existsSync(pathToPackageJson)) {

There have been an (unmerged) attempt at resolving this: #462. One possible (different) way of solving this could be to let the presence of an .importjs.js file have precedence. So instead of just stopping at the first package.json we find we could first scan for .importjs.js, then make a fallback scan for package.json.

[mikabytes]

Yet another approach might be to put the highest precedence on .importjs-root file and keep the existing behavior the same. Very few people are using that file due to it being undocumented so we risk less breaking changes.

Could you let me know if this is still something that needs to be implemented? I could give it a go.