[project-references] TS2307 with direct file imports (imports that bypass an index)

[rosskevin]

TypeScript Version: 3.1.0-dev.20180831

Search Terms:
TS2307 with direct file imports (imports that bypass an index)

Code
Starting from the yarn workspaces learn-a example, change pkg2/index.ts to import the pkg1/foo class directly.

Reproduction: https://github.com/rosskevin/learn-a/tree/yarn-workspaces-TS2307-direct-file-import

// import * as p1 from '@ryancavanaugh/pkg1'; // works
import { fn } from '@ryancavanaugh/pkg1/foo'; // does not work

export function fn4() {
  // p1.fn();
  fn();
}

yields:

packages/pkg2/src/index.ts:2:20 - error TS2307: Cannot find module '@ryancavanaugh/pkg1/foo'.

2 import { fn } from '@ryancavanaugh/pkg1/foo';

Expected behavior:
All direct paths are accessible, just like any standard file resolution.

Actual behavior:
error TS2307: Cannot find module '@ryancavanaugh/pkg1/foo'.

Related Issues:
#26819 is similar (may be the same) but it is focused on esnext usage
#25600

[rosskevin]

Some background - the tedious but working method using aliases with a monorepo (tsconfig at the root):

{
  "compilerOptions": {
    "baseUrl": "./packages",
    "paths": {
      "@ryancavanaugh/pkg1/*": ["./pkg1/src/*"],
      "@ryancavanaugh/pkg1": ["./pkg1/src"]
    }
  }
}

[onehorsetown]

Switching to TypeScript + monorepos has been fantastic, except for this singular issue. You end up having lots of packages for no other reason to namespace things or you have to bubble all of your modules up to the root of the package just so you can access them without exposing the nested directory structure as in:

import { fn } from '@ryancavanaugh/pkg1/src/foo'

Your solution with using the paths configuration will satisfy the compiler, but it ultimately did not work for me because Node was not able to resolve the modules at runtime.

Similar issue: #25682

[rosskevin]

Note: I had to revert project references until this is fixed, but I do have path aliases working without project references.

[garthk]

This is one of a few show-stoppers for project references for us.

[sheetalkamat]

Again this seems like by design. Our module resolution follows what happens as part of node module resolution.

Assume there was no error, then your pkg2/lib/index.js is going to be

"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
// import * as p1 from '@ryancavanaugh/pkg1'; // works
var foo_1 = require("@ryancavanaugh/pkg1/foo"); // does not work
function fn4() {
    foo_1.fn();
}
exports.fn4 = fn4;
//# sourceMappingURL=index.js.map

And that's not going to work. You need to import @ryancavanaugh/pkg1/lib/foo for it to work. compiler never transforms the module references that means you need to provide correct module resolution path

Note --traceResolution gives information about how the resolution was done.

cc @RyanCavanaugh

[rosskevin]

@sheetalkamat if I build/publish pkg1 project, then use it externally, import { fn } from '@ryancavanaugh/pkg1/foo' will work.

Therefore, assuming we are seeking parity with individual project builds, if I use this from a monorepo with project references via pkg2, it should work as well, yet it does not:

$ tsc -b
packages/pkg2/src/index.ts:2:20 - error TS2307: Cannot find module '@ryancavanaugh/pkg1/foo'.

2 import { fn } from '@ryancavanaugh/pkg1/foo'; // does not work

So how can you claim project-references using standard node module resolution if this does not work inside a project-references monorepo, but does if I use a single project build?

[sheetalkamat]

This has nothing to do with project references at all. Here is the trace from module resolution and why it fails.

======== Resolving module '@ryancavanaugh/pkg1/foo' from 'c:/temp/learn-a/packages/pkg2/src/index.ts'. ========
Module resolution kind is not specified, using 'NodeJs'.
Loading module '@ryancavanaugh/pkg1/foo' from 'node_modules' folder, target file type 'TypeScript'.
Directory 'c:/temp/learn-a/packages/pkg2/src/node_modules' does not exist, skipping all lookups in it.
Scoped package detected, looking in 'ryancavanaugh__pkg1/foo'
Directory 'c:/temp/learn-a/packages/pkg2/node_modules/@types' does not exist, skipping all lookups in it.
Scoped package detected, looking in 'ryancavanaugh__pkg1/foo'
Directory 'c:/temp/learn-a/packages/node_modules' does not exist, skipping all lookups in it.
Scoped package detected, looking in 'ryancavanaugh__pkg1/foo'
'package.json' does not have a 'typesVersions' field.
Found 'package.json' at 'c:/temp/learn-a/node_modules/@ryancavanaugh/pkg1/package.json'. Package ID is '@ryancavanaugh/pkg1/foo/index.d.ts@3.0.2'.
File 'c:/temp/learn-a/node_modules/@ryancavanaugh/pkg1/foo.ts' does not exist.
File 'c:/temp/learn-a/node_modules/@ryancavanaugh/pkg1/foo.tsx' does not exist.
File 'c:/temp/learn-a/node_modules/@ryancavanaugh/pkg1/foo.d.ts' does not exist.
Directory 'c:/temp/learn-a/node_modules/@types' does not exist, skipping all lookups in it.
Scoped package detected, looking in 'ryancavanaugh__pkg1/foo'
Directory 'c:/temp/node_modules' does not exist, skipping all lookups in it.
Scoped package detected, looking in 'ryancavanaugh__pkg1/foo'
Directory 'c:/node_modules' does not exist, skipping all lookups in it.
Scoped package detected, looking in 'ryancavanaugh__pkg1/foo'
Loading module '@ryancavanaugh/pkg1/foo' from 'node_modules' folder, target file type 'JavaScript'.
Directory 'c:/temp/learn-a/packages/pkg2/src/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/learn-a/packages/node_modules' does not exist, skipping all lookups in it.
'package.json' does not have a 'typesVersions' field.
Found 'package.json' at 'c:/temp/learn-a/node_modules/@ryancavanaugh/pkg1/package.json'. Package ID is '@ryancavanaugh/pkg1/foo/index.d.ts@3.0.2'.
File 'c:/temp/learn-a/node_modules/@ryancavanaugh/pkg1/foo.js' does not exist.
File 'c:/temp/learn-a/node_modules/@ryancavanaugh/pkg1/foo.jsx' does not exist.
Directory 'c:/temp/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/node_modules' does not exist, skipping all lookups in it.
======== Module name '@ryancavanaugh/pkg1/foo' was not resolved. ========

Especially note how there is no information in packageJson to redirect foo into lib file

Also i dont know what you mean by packaging as a module and it works? Can you explain what are the changes and what are your doing for it to be available for module resolution ?

[rosskevin]

I'm sorry but your comment about resolution does not change the observable/verifiable facts I presented. Quick restatement of the case:

1. I can build/publish pkg1, then use it as I do from pkg2 if I am not using a monorepo (e.g. any npm package).
2. As presented in the project-references monorepo reproduction, pkg2 cannot import a file from pkg1 that is a non-index.

I assume that a project-references monorepo seeks parity with resolutions of files in individually published projects (e.g. any package from npm), correct?

As I mentioned above, I can replicate this standard resolution behavior with path aliases, but project references do not replicate the standard resolution.