Add support for resolving extensions in relative paths

[amosyuen]

Currently relative paths are always ignored, so extensions can't be resolved for relative paths. This change adds support for resolving relative paths.

[codecov[bot]]

Codecov Report

Merging #259 into master will not change coverage. The diff coverage is 100.00%.

Impacted Files	Coverage Δ
src/resolvePath.js	100.00% <100.00%> (ø)

[tleunen]

@fatfisz What do you think? I feel like it could slow down projects compilation if we start checking all paths? At the same time, in big projects, my guess is that most of the paths are already using the root/alias config?

[fatfisz]

I'm more worried about surprises in resolving, but we could always release this as a RC to verify the assumptions. Otherwise I think this is a good change; I wouldn't worry about the potential increase in time.

[amosyuen]

So how should we move forward with this?

[wardpeet]

And it wouldn't work well for the .android.js or .ios.js since the plugin doesn't know which one to use in that case. It shouldn't actually put the extension in this very specific case. I believe it does, most people will have more than one config, one for android and one for ios. They will have set different extensions for each build platform.

I have something like this in config

['module-resolver', {
      extensions: [BUILD_PLATFORM + '.js', '.js']
      stripExtensions: [],
    }],

where BUILD_PLATFORM can be web, android or ios.

this PR does the trick for me already published to our private NPM

[tleunen]

I finally got a use case where I wanted to resolve a relative path as well, but with a specific alias config though. The usecase was to map all *.css files into something else that could work on nodejs.

So I wonder if instead of the custom resolvePathFromRelativeConfig function @amosyuen, it wouldn't be better to just remove the isRelative check in resolvePath and resolve all paths. Doing so shouldn't cause any troubles afaik (do you confirm @fatfisz ?)

[tleunen]

Nvm, it's not safe to run on all paths as is. It can create a breaking changes.

Let's say I have an alias "App": './app. But then I have a file requiring a local file called ./app, it will actually rename my import as ./App which is not correct in this case :/ Modifying the original alias as "^App/(.+)": "./app/\\1", fixes it, but it requires the end user to update his config :/