Module resolution fails when there is a file and directory with same name

[bhgsbatista]

In my TypeScript project I have the following structure:

.
└── Components
    ├── DashboardItem.tsx
    └── DashboardItem
        ├── DashboardItemContent.tsx
        └── DashboardItemHeader.tsx

I import DashboardItem like so:

import DashboardItem from '~/Components/DashboardItem';

In this scenario, Snowpack generates the following import:

import DashboardItem from '../../../Components/DashboardItem/index.js';

It's inserting index.js in front which is incorrect. Any idea how I can get around this problem?

[FredKSchott]

Short term fix: is to do import DashboardItem from '~/Components/DashboardItem.tsx'; and add the file extension youself so that Snowpack doesn't need to guess. If TypeScript gets mad about that, you can also do import DashboardItem from '~/Components/DashboardItem.js';

Long term: Unfortunately, I think this may be expected behavior for us. The way our resolution algo works, is that we look for ~/Components/DashboardItem on disk, and then if it's a directory we add the index file to look inside that directory. Since we support many file types/extensions, it would be difficult/slow to first search different file extensions to take priority over the directory.

[bhgsbatista]

Could we expose an option to provide an array of extensions to attempt to resolve before checking for the presence of a directory?

Or check upon returning the index path, check it exists, and if not fall back to this extension checking behavior (it could default to ['js', 'ts', 'jsx', 'tsx']?

This seems like it'll trip up people coming into Snowpack expecting their TypeScript code to work considering it compiles in TS.

[FredKSchott]

As general advice: If you have both Foo/index.tsx and Foo.tsx, I wouldn't recommend importing either one of those by ./Foo since it's not really clear to the system which you're trying to import (and you end up relying on the order of each platform's implementation, which we'd love to follow but we have an implementation reason why that's hard for us to do.)

If someone could do some perf testing to find out how much slower glob('DashboardItem*') is compared to a direct fs.stat('DashboardItem') call, to confirm that perf isn't harmed, I'd be +1 on changing our default behavior to prioritize files over directories when no file extension is found in the import.

[bhgsbatista]

To respond to your advice, that seems reasonable, unfortunately TypeScript is against having file extensions in the from clause:
An import path cannot end with a '.tsx' extension. Consider importing './PlanningCreator/SaleOrganizerDialog' instead.ts(2691)

It's also not realistic for me to change my entire app to add .js extension (which TS seems to not mind, for some reason) on all places that are ambiguous. It's a significantly large app.

On the perf issue, if we did the glob search inside the if (stats && stats.isDirectory()) we can minimize the cost by only searching for files matching a certain extension when we're importing a folder.

I think the most correct fix here would be to provider users a configuration option so they can work around the issue if they encounter it, but for other users there would be minimal or no perf impact.

NOTE: Using glob is probably not a good idea since it could match files or directories that are partial matches.

[FredKSchott]

It's also not realistic for me to change my entire app to add .js extension (which TS seems to not mind, for some reason) on all places that are ambiguous. It's a significantly large app.

Fair enough :)

Using glob is probably not a good idea since it could match files or directories that are partial matches.

True, I guess what we'd really be looking for is glob(['DashboardItem'], ['DashboardItem.*']) to prevent partial matches. I'd still prefer that we match our default resolution with TS, Node, etc. if possible, vs. making this config only. If we did go the config route, I'd probably push to default to [] so that behavior is consistent across all file types (JSX, TS, TSX, Svelte, Vue, etc).

[FredKSchott]

Update: this should be fixed in Snowpack v3.0

[akdor1154]

I am still seeing this problem in Snowpack v3.1.1 .