Output types alongside JS files, enable declaration maps

[meyer]

This PR sets the type declaration output directory to be the same as the JS output directory so that types are automatically pulled in for folks who are requiring things from dist.

I’ve been spelunking around in the internals of ts-loader to see how I can get access to the compiler/checker. I’ve had to use a yarn link’d copy of ts-loader with the change contained in this PR because types aren’t matching up for files in dist.

While I was at it, I enabled declaration maps too.

Current (hella nasty) workaround:

const { getTypeScriptInstance } = require('ts-loader/dist/instances') as typeof import('ts-loader/dist/types/instances');
const tsLoader = require('ts-loader') as typeof import('ts-loader/dist/types/index');

[meyer]

Looks like tests are flaky? The current test failures are timeout issues when running npm install.

[johnnyreilly]

The tests are flaky (well the comparison ones certainly - execution tests are far more reliable). I've retriggered; kinda surprised that failure happened.

Thanks for raising this PR. It's really helpful if people submitting PRs can explain what use case this unlocks. Would you be able to explain what these changes would do for you? What's the itch you're trying to scratch? Context is everything 🤗

[johnnyreilly]

That test issue is curious... https://stackoverflow.com/questions/58172688/incorrect-integrity-when-fetching-from-the-cache

[johnnyreilly]

I think we're bumping on this... yarnpkg/yarn#7584

PS Hi @arcanis! 😄

[arcanis]

Howdy 😄

The 1.19.0 had some issues that got patched in the 1.19.1 - can you try it?

[johnnyreilly]

Thanks for commenting @arcanis! I want to do that and I'm just trying to puzzle out how.

I suspect that a bunch of other people may be bumping on this so maybe it's a good idea if I write up what I'm experiencing so others can find this and fix themselves. The problem is experienced in my GitHub action where I'm running my tests:

https://github.com/TypeStrong/ts-loader/blob/master/.github/workflows/push.yml

Now this works by installing node using this common action: https://github.com/actions/setup-node (loads of people are using this). I don't understand GitHub Actions well enough but somehow yarn is being installed. Weird thing; I can't find mention of yarn being installed in that action even thought it's clearly bringing it in somehow.

I guess I could add in a new step to upgrade yarn maybe? Something like this:

      - name: upgrade yarn
        run: npm install yarn -g

Maybe that's worth a try... Feel like I'm debugging GitHub Actions rather than yarn here 😄

Feel like there should be another way, still.... Let's try: #1027

PS I'm presently wearing the yarn T-shirt you sent me! (it's very comfy)

---

Update - my tweak seemed to do the job. I've merged it for now; I'm curious to know if I'm going the right way about this. If anyone has any thoughts then please do share!

[meyer]

yay, glad the yarn issue is fixed in latest 🚫🐛‼️

@johnnyreilly My eventual use case—and the reason for this spelunking—is that I’d like to extract type information for each built file using the existing program. I’ve built what I need outside of webpack but I’d like to get it integrated as a loader.

Right now I’m at step 1 though—I’m just trying to import ts-loader in TypeScript code without errors about missing types.

---

@andrewbranch got reeeeeally close to what I was looking for in #887. The realisation he made about needing access to the checker (here: #887 (comment)) is exactly the point I’m at now.

[johnnyreilly]

@johnnyreilly My eventual use case—and the reason for this spelunking—is that I’d like to extract type information for each built file using the existing program. I’ve built what I need outside of webpack but I’d like to get it integrated as a loader.

That sounds super cool! What would you do with it? Some kind of code analysis?

[meyer]

That sounds super cool! What would you do with it? Some kind of code analysis?

My eventual goal is to make React prop interface data available to components at runtime, and I’m attempting to go about it the webpack-iest way. At the moment I have to run the interface data extration bit separately. It works reasonably well but it could be better, and I’m a perfectionist 😩.

Eventually I’d like to add that data to import.meta when support for it lands in webpack (and if it ends up being user-writable).

[johnnyreilly]

sounds exciting! Did you want to update the package.json and CHANGELOG.md? Don't forget to thank yourself!

[andrewbranch]

FWIW, I ended up making typedoc-loader for almost exactly the purpose you’re talking about. It worked pretty well. I archived it only because it kept pinging me about vulnerabilities in old dependencies, and I wasn’t using it anymore and as far as I could tell, no one else was either.

[meyer]

@johnnyreilly done!

@andrewbranch rad, thanks! I saw the repo a while ago and was wondering why you had archived it. I’ll clone it and take it for a spin!

[johnnyreilly]

Thanks @meyer - this should be released at some point over the next couple of hours: https://github.com/TypeStrong/ts-loader/releases/tag/v6.2.1

https://github.com/TypeStrong/ts-loader/releases/tag/6.2.5 (I messed up the git tags during the GitHub Actions migration)

https://github.com/TypeStrong/ts-loader/releases/tag/6.2.6 (I wasn't paying attention - I haven't had coffee yet)