Match on files within top-level depedencies

Folks may want to import files from within packages they depend on. I think we need to include these files, or a subset of these files in the files that we match on. This may end up causing relevance issues, which we might be able to resolve with better ranking, with a stricter opt-in mechanism (see below), or both.

In https://github.com/Galooshi/import-js/issues/340#issuecomment-241788664 I mentioned:

One idea I have is to only consider files in the directories.lib directory specified in the package’s package.json file. This would allow packages to opt in to this behavior which would help us avoid matching on random example files, documentation, test files, and other private modules.

I think we could start by adding this feature and allowing packages to opt in to having the files in their directories.lib directory be matched. We can always expand it later if necessary.

I think we need to do this for 2.0, since we removed lookupPaths.

[hathawsh]

Until this issue is solved, here’s a workaround for material-ui imports. I added this option to my .importjs.js:

    importStatementFormatter: (options) => {
      // Adjust material-ui imports to avoid accidentally importing the entire
      // material-ui bundle.
      let stmt = options.importStatement;
      const match = (
        /import \{\s*([A-Za-z,\s]+)\s*\} from '@material-ui\/core';/.exec(stmt));
      if (match) {
        const names = match[1].split(',');
        stmt = names.map((nameWithWhitespace) => {
          const name = nameWithWhitespace.trim();
          return `import ${name} from '@material-ui/core/${name}';`;
        }).join('\n');
      }
      return stmt;
    },

It seems to do the trick.

[ljharb]

Every single person using lodash 5 and up will be importing deep files from it, for example, and not from within any directory. react-dates also has a number of things that are only accessible via deep imports.

Certainly you’d want to filter out everything that’s not in “main”. Another approach could be, only show things that aren’t required elsewhere, but that’d filter out real entry points too.

As for src, I can see how that’d get tricky when it’s included in the package - but I’d still want those options to show up.

I guess I’d expect the default to be “include all entrypoints from npm-installed modules”, with the option to flip that, and then either an “exclude” or an “include” override list respectively, that was a hash keyed by module name, and with a value that’s a list of patterns.