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

Output while using project references is using the previous dependent package output instead of the current #1114

Closed
jedster1111 opened this issue May 21, 2020 · 7 comments · Fixed by #1136
Assignees

Comments

@jedster1111
Copy link

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

@appzuka
Copy link
Member

appzuka commented May 21, 2020

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.

@johnnyreilly
Copy link
Member

cc @andrewbranch and @sheetalkamat 🤗

@sheetalkamat
Copy link
Contributor

will look into this soon

@sheetalkamat
Copy link
Contributor

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

@sheetalkamat sheetalkamat self-assigned this May 21, 2020
@piotr-oles
Copy link
Contributor

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 :)

@sheetalkamat
Copy link
Contributor

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)

@jedster1111
Copy link
Author

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

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

Successfully merging a pull request may close this issue.

5 participants