Ts-loader: Output while using project references is using the previous dependent package output instead of the current

Created on 21 May 2020  路  7Comments  路  Source: TypeStrong/ts-loader

Been trying to figure out how to set up a repo with yarn workspaces, webpack and typescript project references. Apologies if this is simply a configuration error on my part, but I'm unable to spot what I might have done wrong. Running on Windows 10

Expected Behaviour

  • Freshly clone https://github.com/jedster1111/ts-loader-project-references
  • yarn install
  • yarn webpack within the a workspace

    • I expect b to be built and write output files to b/dist
    • I also expect webpack to ouput a/dist/index.js
    • I can run node index.js inside of a/dist and see output 45
  • Change b/src/index.ts getMeaningOfLife to return 42

  • yarn build inside of a

    • I run node index.js inside of a/dist and see output 42

Actual Behaviour

The first yarn build will fail with:

yarn run v1.22.4
$ webpack
Hash: 32473a9cdaa03043ec8e
Version: webpack 4.43.0
Time: 808ms
Built at: 05/21/2020 1:01:35 AM
                       Asset       Size  Chunks             Chunk Names
     ../../b/dist/index.d.ts   53 bytes          [emitted]  
       ../../b/dist/index.js  149 bytes          [emitted]  
../../b/tsconfig.tsbuildinfo    6.3 KiB          [emitted]  
                  index.d.ts   11 bytes          [emitted]  
                    index.js   4.06 KiB    main  [emitted]  main
Entrypoint main = index.js
[./src/index.ts] 140 bytes {main} [built] [1 error]

ERROR in ./src/index.ts
Module not found: Error: Can't resolve 'b' in '/c/coding/jedster1111/ts-loader-project-references/a/src'
 @ ./src/index.ts 3:12-24

ERROR in /c/coding/jedster1111/ts-loader-project-references/a/src/index.ts
./src/index.ts
[tsl] ERROR in /c/coding/jedster1111/ts-loader-project-references/a/src/index.ts(1,32)
      TS2307: Cannot find module 'b' or its corresponding type declarations.
error Command failed with exit code 2.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

If you check b/dist index.js does actually exist at this point.

If you run yarn build again, webpack will complete successfully.

Another interesting thing to note is if you update getMeaningOfLife to return 42. Build webpack and run the built index.js. I get the old value, 45. Re-run webpack and run the build file again, I now get 42.

It seems like the dependant projects are getting built, but not actually used in the webpack output.

Location of a Minimal Repository that Demonstrates the Issue.

https://github.com/jedster1111/ts-loader-project-references

Most helpful comment

Just tried it out and it's looking good!
Thanks everyone that looked into this 馃憦

All 7 comments

What is happening is that that the import statement from project a imports the file b/dist/index.js because that is what is specified as the main option in b's package.json .

Project b is built because it is referenced in a/tsconfig.json but the output of the build to b/dist/index.js happens after the old index.js has already been imported into project a. This is why the code included when a is built always includes the previous build of b and why it fails on the first build.

This can be solved by changing project b's package.json to reference src/index.ts as the main entry point:

  "main": "src/index.ts",

If you are actively developing project b this seems like the best solution. Project a will always include the latest code from project b. If you plan to publish project b it can be built and the dist/index.js file used in the published package.json as part of the publishing flow.

Although this solution works I am still not sure the behaviour is correct. The build option on tsc and the projectReferences option on ts-loader are supposed to rebuild all dependent projects and use them as required. If we are linking to the typescript code rather than the built code in dist we are not really using this feature and the build in b/dist is a waste of time. You do still need to set projectReferences to true for the above flow to work.

cc @andrewbranch and @sheetalkamat 馃

will look into this soon

Ok, this turns out to be in memory file not knowing symlinks.. if these werent symlinks things would have worked out. Will probably be wont be able to work on this before end of next week

In the fork-ts-checker-webpack-plugin to deal with project references, I use memfs. I also had a problem with symlinks and this is how I resolved it: https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/blob/alpha/src/typescript-reporter/reporter/PassiveFileSystem.ts#L158
Maybe it will help :)

Thanks @piotr-oles i had something similar in my mind since we do something close to that in typescript when trying to mimick d.ts files from referenced projects are present even if they are not (https://github.com/microsoft/TypeScript/blob/master/src/compiler/program.ts#L3607)

Just tried it out and it's looking good!
Thanks everyone that looked into this 馃憦

Was this page helpful?
0 / 5 - 0 ratings