Joining forces with ts-loader?

[johnnyreilly]

Hello awesome-ts-loader folk!

I'm one of the maintainers of ts-loader. I've recently been doing some work to update ts-loader and its test packs. We shipped 1.0.0 last night. As I did this work I came to the conclusion that there is a lot of common ground (unsurprisingly) between awesome-ts-loader and ts-loader itself.

I was wondering how you'd feel about seeing if we could unite ts-loader and awesome-ts-loader somehow. Or perhaps just share some common code. I don't know how much of this is workable but I thought it worth putting it out there. Feel free to turn me down but it seems we might all benefit from pooling our efforts.

If you were interested, here's the areas (as I see them) we'd need to think about:

• atl is designed to support WebPack 2.0. ts-loader is designed to support WebPack 1.0. I'm not totally clear on the differences between the 2 (documentation on WebPack 2 seems relatively sparse) but I understand there isn't a huge gap. I have a feeling that supporting both side by side would be pretty do-able. Perhaps with minor config tweaks. Feel free to tell me more about WebPack 2.

• ts-loader runs continuous integration tests on Linux and Windows; atl just Linux. It'd be straightforward to get atl setup with a windows build and I'd be happy to help.

• ts-loader supports all the way back to ts 1.6. I don't see any reason why atl wouldn't do that just as well. Arguably we could well think about dropping support for 1.6 and 1.7 now (although API wise I suspect things would work with only minor work). Again I'd be happy to help with this / discuss this.

• Both ts-loader and awesome-ts-loader have a need for a sync resolver function. If creating a united loader isn't a realistic proposition I wonder if sharing common code such as this might be realistic?

I'm sure there's more to think about but this is a starting point. My ideal would be to have a unified TypeScript loader for WebPack with a common code base that was built and maintained collectively. How that might come about is something I'd be happy to discuss as much as you like. What do you think?

cc @jbrantly @TheLarkInn

PS stay awesome ;-)

[s-panferov]

Hi @johnnyreilly, thanks for the issue. I too think that we need to unify out code bases and I already started to do this.

My little plan:

• Align configuration options with ts-loader to make switching simpler.
• Test "do everything in a child process for speed" approach on several big codebases.
• Send you a PR with cache and child-process support.

[johnnyreilly]

That's a very little plan 😀

[johnnyreilly]

Ooops - I see it now!

[s-panferov]

Both ts-loader and awesome-ts-loader have a need for a sync resolver function. If creating a united loader isn't a realistic proposition I wonder if sharing common code such as this might be realistic?

I've thought about this for some time and I came up that it's better for us to just rely on TypeScript's module resolution engine because, otherwise, we can break IDE support.

[johnnyreilly]

Sounds reasonable. I'm at work right now and so won't be able to respond for most of today but do you want to think about ways in which I can help you? Now I've finished the ts-loader refactor I'm relatively free to do some other stuff. There's one feature that's being worked on that will add an extra option to ts-loader (for vuejs support - details here) but I think that will work out being pretty minor when it comes to changes.

[johnnyreilly]

Just seen the plan; sounds good 😄 Would you like a PR for the CI on Windows support?

[wclr]

What will be the basis for joined forces ts-loader or atl?

[s-panferov]

@whitecolor It will be ts-loader

[TheLarkInn]

Really excited to see this come to fruition. Please let us know if there is any way that the webpack organization can help. Also, we have a private slack for third party loader and plugin authors if you both are interested @johnnyreilly @s-panferov. Just shoot me an email to sean.larkin@cuw.edu if interested and I'll send you an invite.