Chain custom loaders to ts-loader

[TheLarkInn]

Is there any way to chain custom loaders to ts-loader.

Currently when you attempt to mutate a ts file before it makes it to ts-loader, the modifications are ignored. It appears it is because the typescript api is picking up the assets in the project rather than webpack serving .ts files to it.

For example, awesome-typescript-loader has a useWebpackText: feature which fixes this. Is there anysupport for this?

[jbrantly]

Theoretically it should "just work" due to this. I'm guessing since you're posting this issue that it doesn't? There isn't currently a test for it unfortunately.

[TheLarkInn]

From what I can tell it does not. If you need a generic custom loader I can whip one up.

[TheLarkInn]

https://github.com/s-panferov/awesome-typescript-loader/blob/e71f15551c0c5bfff9188d796a6655c1c263812a/src/index.ts

Looks like the program is marked as dirty off the bat when webpack serves the ts files via the loader. That way the changes are updated in the program.

[johnnyreilly]

Apropos of nothing, welcome back @jbrantly! 🎉👍

[TheLarkInn]

Update, the array loader chain syntax does work, however the string syntax does not.

[johnnyreilly]

@TheLarkInn are you the chap I heard on Adventures in Angular talking about WebPack? If so, I really enjoyed it; well done;

[TheLarkInn]

I am @johnnyreilly. Thank you very much. I'm a strong Webpack ambassador to angular devs. Haha. If you frequent the ts-loader gitter, I'd like to talk to you and/or @jbrantly about the future of ts-loader etc.

[johnnyreilly]

Hey @TheLarkInn,

Update, the array loader chain syntax does work, however the string syntax does not.

I think I've had success with both approaches (assuming I'm understanding your meaning correctly). See this webpack.config.js :

/* eslint-disable no-var, strict, prefer-arrow-callback */
'use strict';

var path = require('path');
var webpack = require('webpack');
var packageJson = require('./package.json');

module.exports = {
  cache: true,
  entry: {
    main: './src/main.ts',

    // common dependencies bundled together packaged with CommonsChunkPlugin in gulp/webpack.js
    vendor: [
      'babel-polyfill',
      'angular',
      'angular-animate',
      'angular-ui-bootstrap',
      'angular-ui-router'
    ]
  },
  output: {
    path: path.resolve(__dirname, './dist/scripts'),
    filename: '[name].js',
    chunkFilename: '[chunkhash].js'
  },
  module: {
    loaders: [{
      test: /\.ts(x?)$/,
      exclude: /node_modules/,
      loader: 'babel-loader?presets[]=es2015!ts-loader'
    }, {
      test: /\.js$/,
      exclude: /node_modules/,
      loader: 'babel',
      query: {
        presets: ['es2015']
      }
    }]
  },
  plugins: [ // Check gulp/webpack.js for build specific plugins
  ],
  resolve: {
    // Add `.ts` and `.tsx` as a resolvable extension.
    extensions: ['', '.ts', '.tsx', '.js']
  },
};

Specifically, loader: 'babel-loader?presets[]=es2015!ts-loader' is the string syntax (again, if I have your meaning correctly) and it's worked just great for me. It passes first to ts-loader and then the output goes to babel-loader.

Have I understood you correctly?

UPDATE:

Actually, it looks like your talking about custom loaders being applied before ts-loader. That I haven't tried.

[TheLarkInn]

Other way around, passing a loader to ts-loader

IE:
{test: //, loader:'ts-loader!angular2-template-loader'}

[johnnyreilly]

Yup gotcha.

The right to left evaluation thing always catches me out

[HennerM]

This bug occurs on my project too.

I am using angular2-template-loader to edit the ts files before the compilation, but it looks like only the entrypoint files are transformed. All other files that are imported aren't transformed.

[TheLarkInn]

@HennerM are you using the string-style.of chaining loaders? If so is recommend using the array style.
IE: loaders: ['ts-loader', 'angular2-template-loader']

[HennerM]

It's working now.

for everybody who experience the same issue: the ordering of the resolve.extensions option in the webpack config is important, the .ts extension has to be before .js
e.g

resolve: { extensions: ['', '.ts', '.js'], }

[timocov]

@HennerM @johnnyreilly it still does not work, but I am not sure it is a TypeScript issue (@TheLarkInn wrote in microsoft/TypeScript#9017 about it) or ts-loader.

I have attached a small project with reproducing of the issue.

We use preprocess-loader to remove some parts of the code from certain builds.

Do the following to reproduce the issue:

1. Unzip archive
2. run npm install in the folder
3. run ./node_modules/.bin/webpack --config webpack.config.js

Actual behavior
The build success.

Expected behavior
The build should be failed because Bar::availableOnlyInDev should be removed by preprocess-loader (see Some uncompiled code in main.ts for example).

If you comment declare const baz: Bar; line in main.ts and uncomment const baz = new Bar(); line and re-run build you will get an error as expected.

Seems that the issue happens because TypeScript loads some modules by itself omitting ts-loader, but I am not 100% sure.

[timocov]

Also src/bar.ts is not in webpack's deps list and if you run webpack in watch mode and change this file - it does not make rebuild.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Closing as stale. Please reopen if you'd like to work on this further.

[efreeti]

I'm not sure why is this closed and there is no activity on this issue. I've debug the code for quite a bit and I don't see how this possibly could have ever worked. Unless you specify transpileOnly option for the loader the loader will always go to the file system to get the source it does not use the input provided by webpack. This makes chaining impossible. Especially in the case where my original file is nor ts nor tsx but some custom format transformed to TS and then fed to ts-loader. Actually the behavior in this case is very problematic as ts-loader finds totally invalid syntax on the file system, returns undefined (because it's not ts file) and then compiles the whole project.

[lazarljubenovic]

@efreeti I had the exact same idea and I'm pretty disappointed that this doesn't work. Have you found any workarounds for your use-case?