-
-
Notifications
You must be signed in to change notification settings - Fork 433
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
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:
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 the fork-ts-checker-webpack-plugin to deal with project references, I use |
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! |
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 thea
workspaceb
to be built and write output files tob/dist
a/dist/index.js
node index.js
inside ofa/dist
and see output45
Change
b/src/index.ts
getMeaningOfLife
to return42
yarn build
inside ofa
node index.js
inside ofa/dist
and see output42
Actual Behaviour
The first
yarn build
will fail with: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 return42
. Build webpack and run the builtindex.js
. I get the old value,45
. Re-run webpack and run the build file again, I now get42
.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
The text was updated successfully, but these errors were encountered: