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 types alongside JS files, enable declaration maps #1026

Merged
merged 1 commit into from Oct 23, 2019

Conversation

meyer
Copy link
Contributor

@meyer meyer commented Oct 21, 2019

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
Copy link
Contributor Author

meyer commented Oct 22, 2019

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

@johnnyreilly
Copy link
Member

johnnyreilly commented Oct 22, 2019

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
Copy link
Member

johnnyreilly commented Oct 22, 2019

@johnnyreilly
Copy link
Member

johnnyreilly commented Oct 22, 2019

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

PS Hi @arcanis! 😄

@arcanis
Copy link
Contributor

arcanis commented Oct 22, 2019

Howdy 😄

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

@johnnyreilly
Copy link
Member

johnnyreilly commented Oct 22, 2019

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
Copy link
Contributor Author

meyer commented Oct 22, 2019

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
Copy link
Member

johnnyreilly commented Oct 22, 2019

@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
Copy link
Contributor Author

meyer commented Oct 22, 2019

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
Copy link
Member

johnnyreilly commented Oct 22, 2019

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

@andrewbranch
Copy link
Contributor

andrewbranch commented Oct 22, 2019

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
Copy link
Contributor Author

meyer commented Oct 22, 2019

@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!

package.json Outdated Show resolved Hide resolved
@johnnyreilly johnnyreilly merged commit c276e67 into TypeStrong:master Oct 23, 2019
2 checks passed
@johnnyreilly
Copy link
Member

johnnyreilly commented Oct 23, 2019

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)

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 this pull request may close these issues.

None yet

4 participants