[New]: add no-relative-packages

[tapayne88]

Duplicating #966 and hopefully fixed it 🤞 (sorry if this isn't the process).

[coveralls]

Coverage increased (+5.3%) to 75.918% when pulling 6f5c52c on tapayne88:feature/no-relative-packages into 319d0ca on benmosher:master.

[coveralls]

Coverage decreased (-0.02%) to 97.837% when pulling 0aec1d3 on tapayne88:feature/no-relative-packages into 3e65a70 on benmosher:master.

[tapayne88]

@ljharb is there anything I can do to get this over the line?

[wycats]

@tapayne88 I tried this out from your branch and it improved my workflow dramatically.

One recommendation: right now, the warning suggests importing from package-name/index instead of package-name. It seems like that ought not happen.

One wrinkle: in my case, I am not importing from the same location as the main entry point (which is dist/index.js) because the mistaken import is accidentally the index.ts in the root of the package. I have types pointing at index.ts, but that is probably not a perfect heuristic. In a situation where the import is pointing at an index.ts file that isn't the main entry point, perhaps it's just fine to suggest package-name?

[tapayne88]

hey @wycats, thanks for the feedback! To be honest, the bulk of the work was originally done by @panrafal but I'll try set aside some time to look into your recommendation - it does sound closer to what we want.

If I'm understanding your wrinkle correctly, I think node module resolution should use the "main" field in the package.json first (if available) and resort to the index.js/index.ts second before heading up the filesystem in search of more node_modules folders so I think what you're seeing is the desired behaviour.

[wycats]

@tapayne88 If it finds index.ts in the absence of a types field (even in the presence of main field), I think that would be ok.

[wycats]

@ljharb what do you think of this PR?

[ljharb]

Looks great! Went ahead and rebased, and refactored to use the new moduleVisitor pattern.