Transpiling shared project multiple times as well as other possible tsconfig issues
MatthewCushing opened this issue · comments
If I'm not mistaken, the tsconfig project reference tree you have in /src
and then also within your child leaf nodes on /src/client
and /src/server
are redundant. Right now you have a build script for the server that runs the tsconfig in the /src
directory. This will transpile the server and the shared directories. Then inside of your /src/server
tsconfig you are referencing the shared directory again which then transpiles and overwrites the already transpiled code. It seems you would just need one or the other.
You are also referencing the shared directory in the /src/client
's tsconfig, however you are using webpack to bundle the client and not using tsc
so it's not taking advantage of the project reference unless using ts-loader (which you aren't) which isn't fully supporting typescript project references from what I've last read anyways. It is still bundling some of the shared files in with one of the bundles by following the imports from your files I would assume. Please correct me if I'm wrong on this, I've been looking into finding if any of the main bundlers (rollup, webpack, or parcel) support tsconfig project references and can't seem to find much.
Also, keep in mind that having "types": []
in a tsconfig can cause issues because it will not defaultly grab for any definitely typed packages that you consume and you'll have to manually put the path into that array unless that was your intention for the client to not consume any of the @types
packages.
If I'm way off on this, I'd love to hear a response. I was looking into this and liked what you were doing but the tsconfigs have thrown me off for the past 6 hours or so. Thanks!
It's very interesting what you're saying here, I'll look into it.
ok, so regarding the build-server
script: I just made it compile using the tsconfig.json
under the server
folder (And not the src
folder). I saw that it does output also the shared files.
Regarding the client, and not using ts-loader
: I'm not sure if the@babel/typescript
plugin respects reference projects, but having the reference
to the shared
is useful when working in VSCode, which is working with tsc
for import resolution etc.
I've removed the tsconfig.json
from the src
folder, as it was not used at all.
Having "types": []
is on purpose, as the node_modules
can be used both for the client and the server, using :types": []
will prevent me from importing NodeJs libraries into the client code by mistake. I want to specify them manually (If needed at all). That's also the reason I created a specific tsconfig for tests (Which is referencing jest
and node
in the types
section)
I'd really appreciate your comments before I close this issue.
Thanks for the insights!
Ah dang, I was hoping you might have more info on bundlers respecting project references outside of what I had found but sounds good. In regards to "types": []
, sounds good! Was just making sure it was purposeful.
Why don't you think @babel/typescript
is not respecting project references?
Why don't you think
@babel/typescript
is not respecting project references?
Through various unresolved/closed after thread has gone silent Github issues. However, I just found a webpack plugin that does support it.
The Solution!
https://www.npmjs.com/package/fork-ts-checker-webpack-plugin
Various unresolved Github issues(only results I can find on it aka: No mention of full support) with bundlers in regards to TS Project References
Webpack
TypeStrong/ts-loader#815
TypeStrong/ts-loader#1028
https://stackoverflow.com/questions/55261870/typescript-project-references-with-webpack
https://blog.johnnyreilly.com/2018/09/ts-loader-project-references-first-blood.html
Rollup
ezolenko/rollup-plugin-typescript2#139
Parcel
parcel-bundler/parcel#1839
As far as why I think that @babel/typescript
is not respecting project references, I can't find anything that does say it's respecting it and only roundabout ways via ts-loader and so forth have I found anything mentioning it. If it was supporting it, I would believe there would be an options in regards to project references like allowing it to be a separate bundle with its' own output name.