Within a package, resolving an import to the index of the parent folder ("..") is problematic

[axefrog]

TypeScript Version: 3.0.1-insiders.20180713

Search Terms:
auto import parent relative index

Code
Screenshot taken from VS Code to illustrate; not really a "code" issue as such

Expected behavior:
Note: I am using JavaScript with jsconfig.json

Suggest a location that is a bit more specific than the index file that is probably in the middle of being parsed at the time that the import is resolved.

For example, for the following structure:

/src/index.js
/src/foo/index.js
/src/foo/Foo.js
/src/bar/index.js
/src/bar/Bar.js

While editing Bar, a reference to Foo should resolve as ../foo or ../foo/Foo. At the very least, I should be given the option to resolve it as such. In general, it'd be nice to be able to avoid blind linking to a local or ancestral index.js file via just .. or ..

Actual behavior:
Auto-import is suggesting .. as the path to the file (also can occur with just .). This can cause issues with eagerly-evaluated exports that resolve at parse time - linking to an index file that is in the middle of being parsed can create issues. It also feels kind of sloppy to just point at the parent and hope for the best. In any case, it would be nice if TypeScript could avoid assuming that the developer prefers one style of relative path resolution over another.

Playground Link: n/a

Related Issues: Only issues related to the '../../../../../@xxxxx/....' bug

EDIT: I'm wondering if this is a bug, because I'm noticing most other imports behaving the way I expect. The issue I described above is occurring on a new file I added. I don't know if it's relevant, but the in addition to some wildcard exports, the parent index file also has some stopgap imports and exports implemented directly in that file.

@axefrog Could you share a complete example? What is the content of src/index.js and src/foo/index.js? We already have a test tests/cases/fourslash/completionsImport_notFromIndex.ts (added in #23623) that should be testing for this case, but your example might be more complicated.

[axefrog]

When you say "complete example", are you looking for a copy of a repository? My repo setup is definitely not trivial - I have multiple projects in a root folder, some of which are clones of open source projects of mine, and some of which are private. At least two of the child repos are monorepos in their own right, and the root folder is set up as a local-only monorepo, managed with yarn workspaces in order to help me manage dependencies between the different projects. One of the child monorepos is a JavaScript project and the other is a TypeScript project. In VS Code, I'm using a multi-root workspace to point at each of the primary child projects.

It looks like this:

• Root folder is frptools, and this is one of the VS Code workspace folders
• Within frptools there is a projects folder, which contains a folder for each project I'm managing, and each of these also exist as root folders in my VS Code workspace (I have excluded the frptools/projects folder from the showing up in the workspace because otherwise I'd be able to access individual project folders both via the frptools workspace folder, and via the explicit workspace folder for the respective child project).
• Within projects are about 10-15 child repos/projects
• The project where I have the issue is called salix
• Salix is a monorepo with its own private package.json, and has a child folder packages, containing a subfolder for each of several scoped child packages that make up the salix monorepo.

The issue occurs intermittently within @salix/****, and doesn't seem to follow any consistent pattern, other than that it'll happen consistently with some files and not others. The issue can occur, resolving as either of .. or ., depending on where the export lives, relative to the import location.

I am happy to provide additional details as needed, though obviously providing a copy of the entire setup won't be totally straightforward, so if we can avoid doing so, that would be ideal.

TypeScript doesn't use the vscode workspace, but it does use jsconfig.json. So everything outside of the directory containing jsconfig.json should be irrelevant (since this is a relative import, not to something outside of the directory). I'm hoping you'll be able to reproduce the error in a test project consisting of just some file in core, and the index.ts it's importing from, combined with jsconfig.json.

[axefrog]

I understand TS isn't a part of vscode - it's just where I'm doing my work, hence the references to it. Honestly I don't even know how to reproduce the issue consistently as-is...

Given that we know what the actual result is when the problem occurs, and obviously that particular result is generally undesirable anyway, is there any way of somehow enabling some kind of logging or trace that I could give to you when it does happen? What kind of data would help you see, retrospectively, what might have caused the problem?

When the error does happen, I would take a snapshot of the current file and paste it into a sample project, along with the file you're importing from. And possibly jsconfig.json. Then see if the error still happens there.

[axefrog]

I haven't seen the error happen for a while. That said, "I would take a snapshot of the current file and paste it into a sample project" is not really a straightforward thing to do. As you can see in the screenshot, there are many projects with many interdependencies between things, including multiple node_modules folders and yarn-workspaces-managed symlinked references between projects as well. Moving things into a sample project won't work because all the dependencies will disappear, which would mean other issues will get in the way of trying to reproduce the problem.

Is there no way to collect a trace of some kind that could illustrate how TS made a particular decision and it why it rejected other potential options?

#27006 may help, although in this case the content and path of the file(s) imported from matter too.