-
-
Notifications
You must be signed in to change notification settings - Fork 431
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
Fixed issue with incorrect output path for declaration files #822
Fixed issue with incorrect output path for declaration files #822
Conversation
I really appreciate the detailed PR - that's very helpful indeed!
Could you provide some details around what workarounds people might be making use of? |
I just mean that people have adapted to use a path relative to the output folder instead of the root. I thought I had during the night was that maybe we can combine the old solution and the new one. If you start your declarationDir with dot-slash, './output', we could use the project root as base. And if you just use 'output' for example it could be relative to the webpack output folder. Still a bit confusing though since |
Cool. Essentially I'm trying to evaluate how "breaking" this change would be. If it's not really that break-y then I'd consider treating this as a fix version-wise. Alternatively we'd have to do a major version bump which I'm less keen on, but if it's appropriate then that's what it should be. Do you have a view? |
Yeah, a major seems unnecessary for this small fix. But still I might require action from the user. I'm not sure what the conventional thing to do is. |
Thanks chap. I'm not going to be online much for the next couple of weeks; I'll probably look to ship this with #817 when the time comes. |
Sound good! Just ping me when the time comes! |
Thank you very much for this fix. 😍 I've tried this PR. It works properly. (Both with But it works only if I set
If I forget to set
Maybe we need note for reminding users to set
|
@gluons I would have to say that it's intended (but maybe unwanted in some cases?). It's TypeScripts default behavior to do this. If you don't add outDir or declarationDir it might be intended, and you could get annoyed by a warning, since it's in the context of TypeScript isn't wrong. What does @johnnyreilly think? |
Then that's what ts-loader should do 😁 As a general rule of thumb, ts-loader aims to be a drop in replacement for BTW I'm hoping to get this merged and shipped either next week or the week after. |
OK. I get it. |
Hey @JonWallsten, I'm just heading back from holidays. I've been thinking; although this is a minor change, you're right that it's technically a breaking change. As much as I don't want to bump the version number; ts-loader seeks to be a good semver citizen. So it's time to bite the bullet. Please could you:
Then I'll close my eyes, weep a bit and push out the major version. Cheers! |
@johnnyreilly Sure. I'll fix it before nightfall! And don't worry, it seems like it's fashion to bump majors all the time now anyways ;) I mean, look at Chrome 68! |
Thanks for your work @JonWallsten! Released with https://github.com/TypeStrong/ts-loader/releases/tag/v5.0.0 |
Perfect! No worries! Happy to help for my own cause! ;) |
You mean 69? |
In regards of: #190
I'll try to explain the fix:
Below is the code where we prepare the relative path for the d.ts files so we can add them to Webpack's compilation assets.
Example
Project root: /home/user/jon/projects/a/
[webpack.main]: index.ts
[webpack.output.path]: /home/user/jon/projects/a/dist/
[compilerOptions.declarationDir]: ./dist/typings/
[Scope variables]
[compilation.compiler.context]: /home/user/jon/projects/a/
[compilation.compiler.outputPath]: /home/user/jon/projects/a/dist/
[Other]
All relative assets in [compilation.assets] will have [compilation.compiler.outputPath] as base it seems.
Results
What will happen here is that
path.relative
will return a relative path with compiler.context (project root) as a base. So when TypeScript compiler outputs /home/user/jon/projects/a/dist/index.d.ts (declarationDir is relative to the project root),path.relative
will strip the project root and we will end up with dist/index.d.ts. It looks correct, right? Well, if we would store the compiled files relative to the project root it would. The issue is that compilation.assets seems to equal webpack.output.path.So we'll end up with this:
By changing
compilation.compiler.context
->compilation.compiler.outputPath
we will get a path relative to the output folder instead.So if we have the same output from the TypeScript compiler: /home/user/jon/projects/a/dist/index.d.ts and we strip away /home/user/jon/projects/a/dist/ instead, we end up with index.d.ts. The result would be:
Note that this might be a breaking change since people probably has workarounds or have adapted to this way. Myself included.