Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

module with same name as directory #55

Closed
tkhyn opened this issue Jul 15, 2016 · 2 comments
Closed

module with same name as directory #55

tkhyn opened this issue Jul 15, 2016 · 2 comments

Comments

@tkhyn
Copy link

tkhyn commented Jul 15, 2016

I'm submitting a bug report

  • Library Version:
    1.0.0-beta.4.0.1
    major.minor.patch-pre

Please tell us about your environment (it's probably not very relevant to this issue):

  • Operating System:
    Windows 7

  • Node Version:
    4.4.7

  • NPM Version:
    3.10.6

  • JSPM OR Webpack AND Version
    webpack 2.1.0-beta.17

  • Browser:
    all

  • Language:
    all

Current behavior:
When a module has the same name as a sibling directory, the module is skipped and a warning Unable to resolve path/to/module is raised.

Expected/desired behavior:
The module should be loaded.
STR: simply create a directory (that can be empty) in the same directory and with the same name as an existing module, without the .js extension. The module will be skipped with the above warning.

  • What is the expected behavior?
    The module should be loaded normally.
  • What is the motivation / use case for changing the behavior?
    Having directory with same names as module should not create issues.

My suggestion would be to keep testing for path existence if stats is relative to a directory in ensurePathHasExtension, as below:

function ensurePathHasExtension(fullPath) {
  [...]
  if (!stats || stats.isDirectory())
    try { stats = fileSystem.statSync(fullPathTest = fullPath + '.js') } catch (_) {}

  if (!stats || stats.isDirectory())
    try { stats = fileSystem.statSync(fullPathTest = fullPath + '.ts') } catch (_) {}
  [...]
}

Such a minor change is probably not worth a PR, so unless you insist I'll leave you push that change.

Thanks in advance!

@niieani
Copy link
Contributor

niieani commented Jul 15, 2016

Thanks for contributing and providing the solution along with the example, really helpful @tkhyn!

@EisenbergEffect
Copy link
Contributor

@tkhyn Double thanks for working out the solution!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants