Bug when folder name is the same as package name

[0x62]

I discovered a weird bug today. My folder structure is as follows:

• packages/
  • sys/
    • api/ - @internal/api
      • src/
        • api/
        • other/
        • folder/
    • core/ - @internal/core

Each of the packages in sys has an @lib alias pointing to src.

Running tsc-alias --debug in the @internal/api package returns:

tsc-alias debug: default replacer - alias:  {
  shouldPrefixMatchWildly: true,
  prefix: '@lib/',
  paths: [
    {
      path: 'src/',
      basePath: '/Users/<redact>/packages/sys/api/dist/api',
      isExtra: false
    },
    [length]: 1
  ]
}

The base path has an extra /api appended to it, resulting in an Invalid path warning and no substitution taking place. Meanwhile, the @internal/core package has exactly the same config but no problems.

I changed the structure to

• packages/
  • sys/
    • api-models/ - @internal/api-models
      • src/
        • api/
        • other/
        • folder/
    • core/ - @internal/core

And after running again I get the correct output:

tsc-alias debug: default replacer - alias:  {
  shouldPrefixMatchWildly: true,
  prefix: '@lib/',
  paths: [
    {
      path: 'src/',
      basePath: '/Users/<redact>/packages/sys/api-models/dist',
      isExtra: false
    },
    [length]: 1
  ]
}

I can recreate the same issue in @internal/core by adding a core folder to the src directory.

[Chrisdo82]

I ran into the same issue. Did you find a workaround without renaming the folder?

[0x62]

@Chrisdo82 no, I just changed the folder name and moved on after reporting

[zhouzi]

I ran into the same issue and the workaround for me was to disable the base-url replacer (in tsconfig.json):

"tsc-alias": {
  "replacers": {
    "base-url": {
      "enabled": false
    }
  }
}

In my case, I have a folder named "react" and a dependency with the same name ("react"). So: import ... from "react"; was turned into import ... from "../react";.

[SStranks]

The base-url replacer code needs to be reworked so it checks for the existence of a valid dependency first and aborts if one exists.

[zhouzi]

The issue is that it fails to differentiate a local import with a package import. Local imports always start with a prefix (either a path ./ or an alias ~/), as opposed to packages.

If the imports lacks a prefix, then an existing dependency takes precedence.

[SStranks]

The issue is that it fails to differentiate a local import with a package import. Local imports always start with a prefix (either a path ./ or an alias ~/), as opposed to packages.

Not with the tsconfig baseUrl; if you specify a base-url e.g. ./src you can write import foo from 'utils/bar' and typescript will look for ./src/utils/bar. Which is the point of the replacer, it emulates that functionality. See TS Docs/base-url

What base-url.replacer.ts fails to do is what typescript does, where it checks for the existence of a package first before checking if there's a potential path using base-url - require.resolve could be used to check this. Currently it just assumes that any non-relative import must be a base-url type import, which causes a naming collision.

[zhouzi]

Oh yeah, you're right. I usually combine it with an alias, but since it's optional, both use cases need to be considered. Checking for a matching dependency seems to be the universal approach 👍