WebPack ts-loader compiling all files when I only want it to run in one folder/file

Question

I found a problem in my app structure and build process using WebPack, TypeScript, and TS-Loader that I thought was caused by TypeScript 2.1.4, but apparently was there the whole time.

You can see all the details from my other post: TypeScript 2.1.4 breaking changes in webpack ts-loader

In short, I have Gulp and WebPack set to an entry point of /client/app.ts which for now has almost nothing in it (certainly nothing referencing /server/) but the TypeScript compilation stage of the WebPack build process is still trying to run on /server (and in my other post, showing a compilation error from the Server folder, when it should only be running from the Client folder).

What am I doing wrong and how can I fix it so it only runs on /client/.ts files, and specifically walk the structure from app.ts?

Here's my repo showing everything I'm working with so far: https://github.com/CmdrShepardsPie/test-ts-app/tree/develop

Thanks

Pomp

Looking at your other question - I would remove gulp entirely from your project. It doesn't look like it's giving you any benefit and only adds confusing to the build pipeline – Originative

You can exclude paths from loaders with exclude: /server\// in the loader config – Originative

I'm using Gulp to compile the server, I'll add a link to the repo to my question for full reference. – Pomp

I wouldn't think I'd need to include/exclude anything if I'm passing in the path and/or files to work on specifically. – Pomp

Why not use webpack alone to compile the server? – Originative

@AndyRay I can do that? (New to webpack here) if you'll check out my gulp file, I'm running node afterwords and refreshing it when it changes. – Pomp

@ChrisSimpson did you ever work this out? I'm experiencing exactly the same, I'd have expected that the TS files wouldn't all be compiled, but apparently this is because the typescript compiler does that (see: github.com/s-panferov/awesome-typescript-loader/issues/359 , this references awesome-typescript-compiler but the concept is the same) ... – Libelee

I'm a bit late, but I've just run into the exact same problem with both ts-loader and awesome-typescript-loader. The solution (perhaps slightly inelegant, but easy) is to create an empty .ts file anywhere and specify that as the input in tsconfig.json. This way tsc will process the files from the webpack loader and this empty file each time it's invoked, but it'll leave the other files alone. – Mishnah

What helped a lot for me was switching my monorepo setup to use Typescript Project References, as described here. Took some work to get it set up, but everything works together smoothly now. – Lipread

Answer 1

You can work around this bug by specifying the option onlyCompileBundledFiles in your webpack.config.js like so

module: {
    rules: [
        {
            test: /\.tsx?/,
            use: [{loader: 'ts-loader', options: {onlyCompileBundledFiles: true}}],
        }
    ],
},

I still find it astonishing that ts-loader is broken by default, but at least there's a workaround.

Nymph

This is the answer. Thank you. – Douglasdouglashome

Thanks for this, this solves an issue I was having where my entire Express application (built in TypeScript) was being included into my public directory (where Webpack compiles to) rather than just my outputted bundle. – Ledeen

Just an update, it is now 2020 and ts-loader STILL exhibits this silly behavior. Why it auto-compiles ALL ts files is beyond me but this is the world we live in, apparently. Bonkers. – Unworldly

Thanks @Unworldly for confirming in 2020 - I was also about to uninstall everything to find this bug – Plunge

Amazing this is still broken 3 years later. – Annettaannette

Keep in mind that this breaks compatibility with global .d.ts files or other type definitions that are not part of your imported files. – Komara