typestrong / fork-ts-checker-webpack-plugin Goto Github PK

I'll fix it.

Hello. Just migrated to webpack 3 and trying to setup fast TS compilation, but stumbled on following error. Problem occurs for TS 2.6.x but not for e.g. 2.1.4. Any hints on what can be the cause? Maybe some broken dependency? If i proceed working and save files same error appears again and again.

Environment:

Windows 7x64
webpack 3.10.0
node 6.11.0
npm 3.10.7
typescript 2.6.2
fork-ts-checker-webpack-plugin 0.2.9
ts-loader 3.2.0

Plugin is created without options and here's ts-loader config:

{ 
  test: /\.tsx?$/, 
  loader: 'ts-loader', 
  options: {
    // disable type checker - we will use it in fork plugin
    transpileOnly: true,
    happyPackMode: true
  } 
}

Error:

Starting type checking service...
Using 1 worker with 2048MB memory limit
 67% building modules 982/1020 modules 38 active ...s\user-monitor3\UserStore.tsc:\nidu\dev\juno\juno\node_modules\fork-ts-checker-webpack-plugin\lib\service.js:22
        throw error;
        ^

TypeError: Cannot read property 'getLineAndCharacterOfPosition' of undefined
    at NormalizedMessage.createFromDiagnostic (c:\nidu\dev\juno\juno\node_modules\fork-ts-checker-webpack-plugin\lib\NormalizedMessage.js:15:39)
    at Array.map (native)
    at IncrementalChecker.getDiagnostics (c:\nidu\dev\juno\juno\node_modules\fork-ts-checker-webpack-plugin\lib\IncrementalChecker.js:125:58)
    at run (c:\nidu\dev\juno\juno\node_modules\fork-ts-checker-webpack-plugin\lib\service.js:13:31)
    at process.<anonymous> (c:\nidu\dev\juno\juno\node_modules\fork-ts-checker-webpack-plugin\lib\service.js:38:5)
    at emitTwo (events.js:106:13)
    at process.emit (events.js:191:7)
    at process.nextTick (internal/child_process.js:758:12)
    at _combinedTickCallback (internal/process/next_tick.js:73:7)
    at process._tickCallback (internal/process/next_tick.js:104:9)
 94% asset optimization

Should be simple to implement - see details here: webpack/webpack#6064 (comment)

I should be able to take a look. (Unless someone else gets there first!)

Hi,

When I use ForkTsCheckerWebpackPlugin in webpack, completion completes successfully but somewhere produce errors.

ERROR in O:/code/vue/vts/node_modules/@types/bluebird/index.d.ts(731,37):
TS2304: Cannot find name 'Iterable'.
ERROR in O:/code/vue/vts/node_modules/@types/bluebird/index.d.ts(731,69):
TS2304: Cannot find name 'Iterable'.
ERROR in O:/code/vue/vts/node_modules/@types/bluebird/index.d.ts(754,37):
TS2304: Cannot find name 'Iterable'.
ERROR in O:/code/vue/vts/node_modules/@types/bluebird/index.d.ts(754,69):
TS2304: Cannot find name 'Iterable'.
ERROR in O:/code/vue/vts/node_modules/@types/bluebird/index.d.ts(761,38):
TS2304: Cannot find name 'Iterable'.
ERROR in O:/code/vue/vts/node_modules/@types/bluebird/index.d.ts(761,70):
TS2304: Cannot find name 'Iterable'.
ERROR in O:/code/vue/vts/node_modules/@types/bluebird/index.d.ts(771,38):
TS2304: Cannot find name 'Iterable'.
ERROR in O:/code/vue/vts/node_modules/@types/bluebird/index.d.ts(771,70):
TS2304: Cannot find name 'Iterable'.
ERROR in O:/code/vue/vts/node_modules/@types/bluebird/index.d.ts(827,27):
TS2304: Cannot find name 'Iterable'.
ERROR in O:/code/vue/vts/node_modules/@types/bluebird/index.d.ts(827,59):
TS2304: Cannot find name 'Iterable'.
ERROR in O:/code/vue/vts/node_modules/@types/bluebird/index.d.ts(842,27):
TS2304: Cannot find name 'Iterable'.
ERROR in O:/code/vue/vts/node_modules/@types/bluebird/index.d.ts(842,59):
TS2304: Cannot find name 'Iterable'.
ERROR in O:/code/vue/vts/node_modules/@types/bluebird/index.d.ts(856,27):
TS2304: Cannot find name 'Iterable'.
ERROR in O:/code/vue/vts/node_modules/@types/bluebird/index.d.ts(856,59):
TS2304: Cannot find name 'Iterable'.
ERROR in O:/code/vue/vts/node_modules/@types/bluebird/index.d.ts(869,27):
TS2304: Cannot find name 'Iterable'.
ERROR in O:/code/vue/vts/node_modules/@types/bluebird/index.d.ts(869,59):
TS2304: Cannot find name 'Iterable'.
ERROR in O:/code/vue/vts/node_modules/@types/bluebird/index.d.ts(883,27):
TS2304: Cannot find name 'Iterable'.
ERROR in O:/code/vue/vts/node_modules/@types/bluebird/index.d.ts(883,59):
TS2304: Cannot find name 'Iterable'.
ERROR in O:/code/vue/vts/src/router/index.ts(3,24):
TS2306: File 'O:/code/vue/vts/src/components/HelloWorld.vue' is not a module.

tsconfig

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": [
        "src/*"
      ]
    },
    "sourceMap": true,
    "experimentalDecorators": true,
    "target": "es5",
    "module": "es2015",
    "moduleResolution": "node",
    "lib": [
      "dom",
      "es5",
      "es2015.promise"
    ],
  
    "types": [
      "jest",
      "node",
      "vue",
      "bluebird",
      "lodash"
    ],
    "typeRoots": [
      "./node_modules/@types",
      "./node_modules/vue/types",
      "./src/"
    ]
  },
  
  "include": [
    "./src/**/*.ts",
    "./src/**/*.vue"
  ],
  "exclude": [
    "./node_modules"
  ]
}

webpack:

'use strict'
const path = require('path')
const utils = require('./utils')
const config = require('../config')
const vueLoaderConfig = require('./vue-loader.conf')
const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin')

function resolve(dir) {
  return path.join(__dirname, '..', dir)
}


const createTsLintingRule = () => ({
  test: /\.ts$/, // tslint doesn't support vue files
  enforce: 'pre',
  loader: 'tslint-loader',
  include: [resolve('src'), resolve('test')],
  options: {
    formatter: 'grouped',
    formattersDirectory: 'node_modules/custom-tslint-formatters/formatters',
    typeCheck: true
  }
})

module.exports = {
  context: path.resolve(__dirname, '../'),
  entry: {
    app: './src/main.ts'
  },
  output: {
    path: config.build.assetsRoot,
    filename: '[name].js',
    publicPath: process.env.NODE_ENV === 'production' ?
      config.build.assetsPublicPath :
      config.dev.assetsPublicPath
  },
  resolve: {
    extensions: ['.vue', '.js', '.ts', '.json'],
    alias: {
      'vue$': 'vue/dist/vue.esm.js',
      '@': resolve('src'),
    },
    modules: [
      "node_modules"
    ]
  },
  plugins: [
    new ForkTsCheckerWebpackPlugin({
      vue: true,
      tsconfig:path.resolve("tsconfig.json"),
      diagnosticFormatter: "ts-loader",
      skipLibCheck: true,
      tslint: config.dev.useTslint ?  path.resolve("tslint.json") : false,
      watch: './src' // optional but improves performance (less stat calls)
    })
  ],
  module: {
    rules: [

      ...(config.dev.useTslint ? [createTsLintingRule()] : []),
      {
        test: /\.vue$/,
        loader: 'vue-loader',
        options: vueLoaderConfig
      },
      {
        test: /\.js$/,
        use: utils.scriptLoaders(vueLoaderConfig.scriptLoadersOptions).js,
        include: [resolve('src'), resolve('test'), resolve('node_modules/webpack-dev-server/client')]
      },
      {
        test: /\.ts$/,
        use: utils.scriptLoaders(vueLoaderConfig.scriptLoadersOptions).ts,
        include: [resolve('src'), resolve('test')]
      },
      {
        test: /\.html?$/,
        loader: 'raw-loader' // Required for karma test runner
      },
      {
        test: /\.(png|jpe?g|gif|svg)(\?.*)?$/,
        loader: 'url-loader',
        options: {
          limit: 10000,
          name: utils.assetsPath('img/[name].[hash:7].[ext]')
        }
      },
      {
        test: /\.(mp4|webm|ogg|mp3|wav|flac|aac)(\?.*)?$/,
        loader: 'url-loader',
        options: {
          limit: 10000,
          name: utils.assetsPath('media/[name].[hash:7].[ext]')
        }
      },
      {
        test: /\.(woff2?|eot|ttf|otf)(\?.*)?$/,
        loader: 'url-loader',
        options: {
          limit: 10000,
          name: utils.assetsPath('fonts/[name].[hash:7].[ext]')
        }
      }
    ]
  },
  node: {
    // prevent webpack from injecting useless setImmediate polyfill because Vue
    // source contains it (although only uses it if it's native).
    setImmediate: false,
    // prevent webpack from injecting mocks to Node native modules
    // that does not make sense for the client
    dgram: 'empty',
    fs: 'empty',
    net: 'empty',
    tls: 'empty',
    child_process: 'empty'
  }
}

I'm new to the FTCWPlugin, but I'm having a hard time believing that my experience is the norm.

Libraries
React: 15.4
Typescript: 2.4.2
ts-loader: 2.3.7
fork-ts-checker-notifier-webpack-plugin": "^0.2.0",
fork-ts-checker-webpack-plugin": "^0.2.8",
cache-loader: 1.2
thread-loader: 1.1.2

I'm using the thread-loader method which has cut my initial compile from ~4minutes to >1min, so keeping this setup is very desirable. When I compile via cli, here's what I see:

1. Basic setup outputs, nothing crazy
2. Massive (100+) outpouring of tslint or FTCWP errors (I'm not sure how to differentiate atm, and the 'massive' part is likely from moving from TS 2.2 to 2.4 and updating tslint/tslint-react)
3. errors stop being listed, entire CLI is cleared, and I'm left with "Compiled Successfully! ..."

Updating files results in exact same output of steps 1, 2, 3, so no help there.

Couple questions I have:

1. I like the ts-loader style of interrupting the website with whatever error has come up and forces you to fix it. How do I get that back? From reading the docs, I can see that using happyPackMode: True on ts-loader disables emitting problems to webpack - is there any recourse?
2. Why are all these errors simply being dismissed and my build showing successful?
3. If I put obviously incorrect code in my Typescript the build does not fail - what is happening here? For example <div asdf sytle="hi" and foo={''} /> still compiles, even though I'm sure the list of errors shows those attributes don't exist on
   
   So, does Typescript just compile a broken app and assume it's fine? Is it up to me every time to check with FTCWP that my build is correct, even though it has compiled correctly?

halp plz thx

When running vue-loader with ts-loader without this plugin, I have to use .vue extension to perform imports. But when enabling this plugin, I have to omit them for build to pass.

See this comparison => Both branches builds with no error.

It would be better embrace default import behavior, but I'm not sure how the underlying webpack configuration is involved ...

Hi,

I am trying to use this plugin into Encore but I am getting this ESLint error.

I have read the rule docs but not sure whats need to be done.

thanks in advance

Is there a way to make it check typescript inside .vue files?
I've tried to use it - and it checks all my .ts files, but don't check TypeScript inside .vue

This is a great project, thanks for it!

When using this in a project with unit tests and/or a bigger project with multiple builds it is easy to miss errors as you are likely to be viewing another terminal. While errors from the editor is usually enough it would be nice if the errors from this plugin would be more noticeable.

Some ideas:

1. Console log them in the browser via the dev server.
   I don't know if it's possible to hook into webpacks support for this or if a custom web socket server and client script would need to be added.
2. Growl/libnotify notifications

Excuse the minimal post; on my phone. An issue was logged against ts-loader; details can be found here:

TypeStrong/ts-loader#602

Essentially this comes down to ts-loader being unable to report errors to webpack when used in happyPackMode ie ts-loader is used with HappyPack or thread-loader to split work over multiple instances

Hey, when I use "extends" in tsconfig, this plugin doesn't seem to pick it up and just gives No type errors found, however the extended tsconfig is definitely picked up in the ts-loader config.

Do you know why this might be?

tsconfig.json

{
  "extends": "../../../tsconfig.json",
  "exclude": [
    "node_modules",
    "packages/frontend"
  ]
}

webpack.config.js

HappyPack({
      id: 'ts',
      threads: 2,
      loaders: [
        {
          path: 'babel-loader'
        },
        {
          path: 'ts-loader',
          query: {
            happyPackMode: true,
            configFile: path.resolve(__dirname, 'tsconfig.json')
          }
        }
      ]
    }),
    new ForkTsCheckerWebpackPlugin(
      {
        tslint: true,
        tsconfig: path.resolve(__dirname, 'tsconfig.json')
      }
    ),

These tests in vue.spec.js fail if newer tslint installed.

 3) [INTEGRATION] vue should not find syntactic errors when checkSyntacticErrors is false:            
                                                                                                      
     Uncaught AssertionError: expected 1 to equal 2                                                   
     + expected - actual                                                                              
                                                                                                      
     -1                                                                                               
     +2                                                                                               
                                                                                                      
 4) [INTEGRATION] vue should find syntactic errors when checkSyntacticErrors is true:                 
                                                                                                      
     Uncaught AssertionError: expected 2 to equal 3                                                   
     + expected - actual                                                                              
                                                                                                      
     -2                                                                                               
     +3                                                                                               

If we use yarn install, tslint 5.8.0 is installed according to yarn.lock.
If we use npm install, newer tslint (5.9.1 at today) is installed, and above tests fail with this version.

tslint 5.8.0 reports missing semicolon as error, and 5.9.1 reports it as warning.
This is the reason why these tests fail.

I guess tslint version should be fixed in package.json, or test/integration/vue/tslint.json should be changed more version-independent.

Hi,

Thanks for a great plugin! The issue I have is the following:

All files in the program are passed to TSLint for linting. However the program contains not only the files of the application but also any dependencies from node_modules. In my case I have some dependencies with *.ts files which are imported by application.

And while I definitely need them for compilation & type checking I'd prefer not to run TSLint on them.

Do you think it'be possible to have a param like skipLint which would accept string[] of regexp for files which should not be linted? By default it'd filter out node_modules.

Using that results in an error of this nature: 😢

[09:10:53] Problem generating initial assets (js and css) TypeError: Path must be a string. Received true
    at assertPath (path.js:7:11)
    at Object.isAbsolute (path.js:439:5)
    at ForkTsCheckerWebpackPlugin.computeContextPath (C:\source\proverb-react-mobx\node_modules\fork-ts-checker-webpack-plugin\lib\in
dex.js:127:15)
    at ForkTsCheckerWebpackPlugin.apply (C:\source\proverb-react-mobx\node_modules\fork-ts-checker-webpack-plugin\lib\index.js:75:40

Hi,

We recently started using https://github.com/Jimdo/typings-for-css-modules-loader. It creates d.ts files for css-modules providing us with type checking and intellisense on css class names.
The problem is that the d.ts files are typically generated after fork-ts-checker-webpack-plugin is started. It means, the plugin either throws an error that a file is missing or checks an old version of d.ts file.

I suggest to add an async plugin hook fork-ts-checker-service-before-start so I can defer fork-ts-checker-webpack-plugin start up from another plugin.
If it sounds alright, I can create a PR implementing it.

I guess another option would be to add a flag startAfterFinishModules or startAfterCompile so the plugin will start type checking on compilation finish-modules or compiler after-compile

Hello. Thanks for the great plugin - really helped us speed up the build.

We use it together with HappyPack as it's done here:
https://github.com/TypeStrong/ts-loader/tree/master/examples/happypack

Works great with webpack but TypeScript errors aren't showing in webpack-dev-server (we generally use it with overlay option which displays errors in a way they cannot be ignored).

Is there a way to fail dev-server build with fork-ts-checker?

Is it possible to make tslint run with the --fix option?

seems to have issues finding typescript classes in .vue files.
wondering if this is a known issue?

Hey guys, is it possible to use the noEmitOnError from tsconfig.json?

https://github.com/Realytics/fork-ts-checker-webpack-plugin/blob/46fe4212840d028341cd70a1164f069b8d03e35d/lib/index.js#L245-L251

The parent process' env variables such as NODE_PATH are not passed to the child process; hence if you have a localized build env with non standard library paths, the child process' won't be able to load dependencies such as typescript.

A simple fix is to just add a NODE_PATH: process.env.NODE_PATH field here. A more catch all solution would be to merge this local set of params with process.env and pass the result to the child process. Thoughts? Thanks!

Hey!

An idea just occurred to me which might improve performance still when using this plugin with ts-loader.

I've just been pondering usage of "isolatedModules": true, in relation to using ts-loader alongside fork-ts-checker-webpack-plugin. Essentially using this option will speed up compilation times. Which is nice.

However, if we set this option in the tsconfig.json then presumably fork-ts-checker-webpack-plugin will be impacted by this and effectively cease to typecheck. So that's not good.

Would you consider / would it make sense to have fork-ts-checker-webpack-plugin set isolatedModules to false regardless of what it says in the tsconfig.json? If that were the case then we could advise people using ts-loader with fork-ts-checker-webpack-plugin to use "isolatedModules": true, in their tsconfig.json for an extra perf boost.

What do you think?

cc @jamesbrantly

PS this is a badly documented compiler flag - there's a nice blog post on it though: http://weblogs.thinktecture.com/thomas/2016/05/tired-of-waiting-for-typescript-compilation.html

Hello!

It looks like there may be a problem with fork-ts-checker not despawning its services. It's been discussed here: amireh/happypack#167

Do you have any idea what might be causing this?

Is there a way to see the module resolution trace logs like when you run tsc --traceResolution but through this plugin? I'm running into a strange issue where my dev and prod builds compile fine, but my test build (using karma and karma-webpack) fails to compile withTS2307: Cannot find module 'moment'. All builds are using the same tsconfig file, and when I run tsc --traceResolution I can see typescript properly resolve the moment module, so I'm having a difficult time debugging why it is failing to compile only when being run through karma and karma-webpack.

If I could turn on the traceResolution flag and get those logs while running that build, I might get a little better insight.

Thank you for your work on this plugin. This approach improves webpack build times immense, especially incremental times are a lot faster (even in blocking mode).

But there are some issues at the moment that keeps us from using this plugin in the typescript fork of CRA:

• All type checking errors/warnings needs to be forwarded to webpack’s compile lifecycle, cause CRA controls the terminal output (auto clear) and shows errors in the browser.
  -> watch mode needs to block webpack compilation until type checking is done
• File watcher should be configured by default to get the performance improvements
• Displayed type errors should look similar to ts-loader

Additionally to these, I would also like to see support for typed css modules. The main issue here is that the type checking can only be done after the css files were processed cause type definitions for css files will be created on the fly.

I tried to fork this plugin and fix these „issues“. Adding the blocking of the emit phase back in watch mode was quite easy, but adding support for typed css modules was more complex. That’s why I started to work on a POC for this and ended up with a new plugin, written in TypeScript and tested by Jest.

The approach is the same like your plugin, but there are some differences:

1. The type checking starts after all files were built by webpack (seal hook), but the compilation still needs to be packed together and some other magic needs to be done to optimize the bundle.
2. All files are cached by default until they will be invalidated by webpack. This is possible cause we have the information which files were (re-)built, due to first point.
3. Webpack’s built in file watcher is used to watch additional files like type definitions. So theres no need for a secondary file watcher with it’s own configuration.
4. Only files that are used by webpack will be type checked & linted. This is also possible cause of 1.
5. Compilation is always blocked until type checking is done. In my test project type checking was in the most cases faster than webpack on incremental builds.
6. There is no support of type checking cancellation, cause hacks like checking for file existence are too expensive due to the I/O usage (didn’t checked if this was really called every 10ms). This is also superfluous due to the blocking.
7. There are different error formatters for type checking errors (like ts-loader, code frame, …)
8. There is only a single thread for type checking. In my test cases I never saw a benefit on incremental times with more than 1 thread. Question is how many modules needs to be checked to see a benefit for multiple processes here? And the other question is, can we configure this automatically so that the user just defines a maximal number of processes and we optimize the used processes under the hood.
9. it works great with typed CSS-Modules :)

I made some performance comparisons with your plugin (modified to block ) vs. my plugin and your plugin was on the initial built around 10% faster but on incremental builds around 30% slower. But this was on a quite small project. Unfortunately I don’t have a bigger project to test the impact of the blocking mode, the lack of multiple processes and the delayed start of type checking.

@piotr-oles
It would be awesome if you can provide some statics when the multi process starts to make sense. And it would be even more great, when you could find the time to compare it with my plugin. I pushed my changes for the blocking mode to my fork of this plugin.

Regardless of the results, I think it would be good to join forces to get something that works for everyone and is also as fast as possible :)

I'm running an electron application with webpack 3.6, everything is going well but I still have this error

┏ Renderer -------------------

  C:\Users\Devoid\Desktop\VisualCodeTests\projects\wow-client\node_modules\fork-ts-checker-webpack-plugin\lib\service.js:31
          throw error;
          ^

  Error: Debug Failure. ImportClause
      at getDeclarationSpaces (C:\Users\Devoid\Desktop\VisualCodeTests\projects\wow-client\node_modules\typescript\lib\typescript.js:40136:34)
      at checkExportsOnMergedDeclarations (C:\Users\Devoid\Desktop\VisualCodeTests\projects\wow-client\node_modules\typescript\lib\typescript.js:40071:41)
      at checkVariableLikeDeclaration (C:\Users\Devoid\Desktop\VisualCodeTests\projects\wow-client\node_modules\typescript\lib\typescript.js:41142:17)
      at checkVariableDeclaration (C:\Users\Devoid\Desktop\VisualCodeTests\projects\wow-client\node_modules\typescript\lib\typescript.js:41172:20)
      at checkSourceElement (C:\Users\Devoid\Desktop\VisualCodeTests\projects\wow-client\node_modules\typescript\lib\typescript.js:43038:28)
      at Object.forEach (C:\Users\Devoid\Desktop\VisualCodeTests\projects\wow-client\node_modules\typescript\lib\typescript.js:1500:30)
      at checkVariableStatement (C:\Users\Devoid\Desktop\VisualCodeTests\projects\wow-client\node_modules\typescript\lib\typescript.js:41181:16)
      at checkSourceElement (C:\Users\Devoid\Desktop\VisualCodeTests\projects\wow-client\node_modules\typescript\lib\typescript.js:43007:28)
      at Object.forEach (C:\Users\Devoid\Desktop\VisualCodeTests\projects\wow-client\node_modules\typescript\lib\typescript.js:1500:30)
      at checkSourceFileWorker (C:\Users\Devoid\Desktop\VisualCodeTests\projects\wow-client\node_modules\typescript\lib\typescript.js:43125:20)

┗ ----------------------------

I don't know where it comes from and I don't know why.

The project is here if you want to test : https://github.com/DevoidCoding/wow-client

Hi,

i think this issue is related to #23.

the difference is that when adding plugin as devDependencies linter complains.

Is there something that could be done for avoiding this one too?

many thanks in advance

Hi!

Thank you for the cool plugin. It would be nice, if the README could mention some differences when this plugin is used in watch mode (webpack(options).watch) and non-watch mode (webpack(options).run).

E.g. we use new ForkTsCheckerWebpackPlugin({ silent: true }). This will log errors in non-watch mode, but it will not log errors in watch mode. To log errors in both cases with webpacks native logging we need to set new ForkTsCheckerWebpackPlugin({ silent: true, async: false }). Are there more differences?

First - thanks for the plugin and associated speed improvements!

One issue I've seen is that webpack-dev-server will not rebuild when a change is made in a source file that will not emit js. For example, if I have a types.js file that exports nothing but types/interfaces, and I make a change to that file that introduces a type error, I will not see a warning for that error until I change a file that does emit js. Here is an example:

  // types.ts
  export interface Person {
    name:string;
  };

  // mainEntry.ts
  import {Person} from 'types';
  const sally:Person = {name: 'Sally'};

Changes to mainEntry.ts will trigger a rebuild, but updating types.ts with name:number does not trigger a rebuild, and the error is unnoticed.

Relevant webpack config is as follows:

var threadLoader = {
    loader: 'thread-loader',
    options: {
        // leave one cpu for the fork-ts-plugin
        workers: require('os').cpus().length - 1,
    },
};

var babelLoader = {
    // XXX: .babelrc doesn't seem to be respected so we specify options here
    loader: 'babel-loader',
    options: {
        cacheDirectory: true,
        presets: ['es2015'],
    },
};

<snip>
    modules: {
        rules: [
            {
                test: tsSrc,
                exclude: babelExcludes,
                use: [
                    { loader: 'cache-loader' },
                    threadLoader,
                    babelLoader,
                    { loader: 'ts-loader', options: { happyPackMode: true } },
                ],
            },
<snip>
    plugins: [
        new ForkTsCheckerWebpackPlugin({
            tslint: true,
            watch: ['./src', './test', './test_util'], // optional but improves performance (less stat calls)
        }),
<snip>

This is a very weird bug which took me hours to whittle down to a minimal example, so I hope it's of use. Steps to reproduce:

1.  git clone https://github.com/pelotom/fork-ts-checker-bug
    cd fork-ts-checker-bug
    npm install
    npm start
   

2. Everything should compile fine on the first run. Now open the file foo.ts, add a newline or some other innocuous change, and save it.
3. Now there is an error in a completely different file:

   ERROR in /Users/tom/code/fork-ts-checker-bug/index.ts
   (1,25): Cannot find module 'moment'.
   

What the hey!?

Some observations:

• Undoing the change has no effect; the error remains. However modifying index.ts and saving it fixes the problem somehow.
• Killing the watch process and restarting fixes the problem; first builds always work
• The problem only occurs with the no-unused-variable TSLint rule enabled
• If another library besidesmoment is imported in index.ts, it may or may not exhibit the problem. For example, typestyle exhibits the problem but rxjs doesn't. I'm not sure what the commonality is among packages that run afoul of this.

I thought you might be interested to see this: https://medium.com/webpack/typescript-webpack-super-pursuit-mode-83cc568dea79 😉

I've created a simple example repository to reproduce the issue:
https://github.com/alfrescian/fork-ts-checker-issue

I've an index.ts that does the following alias import of a type defined in a namespace:
import foo = myNamespace.foo;
const myFoo: foo = {foo: 'foo'};

when using ts-loader with fork-ts-checker-webpack-plugin then the output is (run npm run fork and check dist/index.js):
var foo = myNamespace.foo;
var myFoo = { foo: 'check' };

JS runtime will complain about myNamespace is undefined.

when using ts-loader without fork-ts-checker-webpack-plugin then the output is (run npm run no-fork and check dist/index.no-fork.js):
var myFoo = { foo: 'check' };

we are heavily using namespaces & these kinds of alias imports in our project & that currently blocks us using fork-ts-checker-webpack-plugin.

it does not make any difference if an ambient or non-ambient namespace is used. (see index.ts in my example)

(issue was created in ts-loader repo but I was informed that's most likely an issue in the plugin: TypeStrong/ts-loader#644 (comment))

@etienne-dldc @smonteil NPM deploy key doesn't work again - please send me a new one

First of all, thank you very much for this awesome plugin! Keep up the good work!

Description
We are building an Angular (v4) application, using webpack, angular2-template-loader and awesome-typescript-loader, and want now to lint our project with an async linter, i.e. fork-ts-checker-webpack-plugin. The setup works fine for files emitting js, but non emitting files (interfaces, html etc) causes a failure in resolving our defined paths in tsconfig.json. For the questionmarks around the html files, angular2-template-loader triggers a build on them from a save in an html file, as expected.

We have identified an "ugly" fix in IncrementalChecker.ts, where our problem disappears by loading programConfig every iteration (i.e. remove if (!this.programConfig) ). This seems to solve the problem.

We have identified that the host.getSourceFile function runs twice for files emitting js, but only once for non emitting files.

Technical spec
@angular/* version 4.3.5
typescript: 2.3.2
"webpack": "^2.4.1"
"tslint": "^5.4.3",

Reproduce
This error could not be reproduced in a new clean repo. Help needed!!!

Happy[ts]: All set; signaling webpack to proceed.
Starting type checking service...
Using 1 worker with 2048MB memory limit
Watching:
/home/aks/advertkit/app/javascript
/home/aks/advertkit/app/views
/home/aks/advertkit/app/assets/stylesheets
/home/aks/advertkit/app/assets/images
/home/aks/advertkit/node_modules/fork-ts-checker-webpack-plugin/lib/service.js:30
    throw error;
    ^

Error: Debug Failure. 
    at typeToString (/home/aks/advertkit/node_modules/typescript/lib/typescript.js:28777:22)
    at reportRelationError (/home/aks/advertkit/node_modules/typescript/lib/typescript.js:34714:34)
    at isRelatedTo (/home/aks/advertkit/node_modules/typescript/lib/typescript.js:34860:21)
    at checkTypeRelatedTo (/home/aks/advertkit/node_modules/typescript/lib/typescript.js:34697:26)
    at checkApplicableSignature (/home/aks/advertkit/node_modules/typescript/lib/typescript.js:40608:26)
    at resolveCall (/home/aks/advertkit/node_modules/typescript/lib/typescript.js:41011:17)
    at resolveCallExpression (/home/aks/advertkit/node_modules/typescript/lib/typescript.js:41163:20)
    at resolveSignature (/home/aks/advertkit/node_modules/typescript/lib/typescript.js:41398:28)
    at getResolvedSignature (/home/aks/advertkit/node_modules/typescript/lib/typescript.js:41430:26)
    at checkCallExpression (/home/aks/advertkit/node_modules/typescript/lib/typescript.js:41479:29)
ts-loader: Using [email protected] and /home/aks/advertkit/tsconfig.json
ts-loader: Using [email protected] and /home/aks/advertkit/tsconfig.json

Can anyone help me why this is happening or how I can dubug this?

TSLint is running on empty script tag content, even when a src attribute is defined.

<template src="./App.html"></template>
<style scoped src="./App.css"></style>
<script lang="ts" src="./App.ts"></script>

This raises tslint errors for missing EOL

ERROR in C:/devel/projects/vue-ts-test/src/App.vue
(3,91): file should end with a newline

Hello!

I've always wondered why this isn't actually written in TypeScript (given that's what it provides checking for). I'm currently hacking locally on porting this to TypeScript. For the most part I just want to see how hard it would be to do (not hard I suspect).

Would you be interested in a PR for this assuming all goes well?

So, my initial build time is now 30..40 seconds VS 60..80, but in incremental builds only type checking takes 4..6 seconds VS 1.5...2 for the whole build which I had before - this is a major degradation.

My config is:

       {
          test: /\.ts$/,
          use: [
            {
              loader: 'ng-annotate-loader',
              options: {
                map: false,
                add: true
              }
            },
            {loader: 'cache-loader'},
            {
              loader: 'thread-loader',
              options: {
                // there should be 1 cpu for the fork-ts-checker-webpack-plugin
                workers: require('os').cpus().length - 1
              }
            },
            {
              loader: 'ts-loader',
              options: {happyPackMode: true}
            }
          ]
        },
// ...
plugins: [
  new ForkTsCheckerWebpackPlugin({checkSyntacticErrors: true})
],

my cpu as reported by Node is

model: 'Intel(R) Core(TM) i7-6567U CPU @ 3.30GHz',   
speed: 3300,

I am running it on MacBook Pro 2016, 13" with 16GB of RAM
Node version - 6.9.5
OS version - 10.12.6 / 10.13.1 (tested on both)

Things I've tried to do to fix a problem and they didn't help:

• specifying 2 workers for ForkTsCheckerWebpackPlugin
• removing cache-loader
• removing thread-loader
• removing both cache- and thread- loaders
• removing ng-annotate-loader
• using watch config property
• restarting the system
• reinstalling npm dependencies from the scratch
• upgrading OS from latest Sierra (10.12.6) to latest High Sierra (10.13.1)

previous webpack config was:

       {
          test: /\.ts$/,
          use: [
            {
              loader: 'ng-annotate-loader',
              options: {
                map: false,
                add: true
              }
            },
            {loader: 'ts-loader'}
          ]
        },

I also noticed that when I remove thread-loader webpack generates .js file (this triggers gulp-livereload task in our case) before type checking is finished, but if I enable thread-loader then .js file is only generated after type-checking is finished.

Builds are filing with latest typescript.

To reproduce:

1. Use the Webpack Dev Server
2. Make sure the config includes ts-loader with transpileOnly = true, and the fork-ts-checker-webpack-plugin
3. Delete a .d.ts file that declares an interface some other .ts file uses
4. Save a .ts file to trigger recompilation
5. You should see an type error about the missing interface that was declared in the .d.ts file
6. Re-add the .d.ts file that was deleted
7. Re-save the .ts file again to trigger recompilation
8. You will still see the same error even though the .d.ts file has been restored

It seems like this is a caching bug. If I use ts-loader with transpileOnly = false, and if I don't use this plugin, then the issue goes away

We use karma-webpack to run our tests. It accepts a singleRun argument in its options object but even when set to true it uses webpack-dev-middleware which always starts webpack via a call to watch(). This produces a false-positive where this line thinks webpack is watching (because the watch-run event is emitted) when it's effectively not. The end result is even after the tests are finished ForkTSCheckerWebpackPlugin stays open because it ignores the done event and never receives an exit event.

Now, I think the clean solution is that that singleRun argument for karma-webpack should not end up making a call to watch() for webpack. That being said, that sounds like a fairly intensive refactor to some fairly frequently used code. Would it be possible to have a singleRun option that's accepted by ForkTsCheckerWebpackPlugin that either A) ignores the isWatching flag if singleRun: true or B) causes the isWatching flag to always stay false when singleRun is true? I can get a PR together really shortly if this is amenable as this is basically a 2 line change either way.

Love the plugin so far as it's improved the speed of our build a ton. Thanks!

Have moved from type checking via ts-loader to this plugin.

However many of the .d.ts files have started showing errors which were not reported earlier by ts-loader. Attaching webpack config and tsconfig

webpack config -

       {
                test: /\.tsx?$/,
                loader: 'ts-loader',
                options: {
                    "transpileOnly": true
                  },
        }

ts config -

{
    "compilerOptions": {
        "module": "commonjs",
        "noImplicitAny": false,
        "removeComments": true,
        "preserveConstEnums": true,
        "jsx": "react",
        "target": "es5",
        "listFiles": true,
        "sourceMap": false,
        "allowUnreachableCode": true,
        "noImplicitUseStrict": true,
        "allowSyntheticDefaultImports": true,
        "experimentalDecorators": true,
        "lib": [
            "dom",
            "es5",
            "es2015",
            "es2015.promise"
        ]
    },
    "transpileOnly": true,
    "reportFiles": ["*.tsx"],   
    "isolatedModules": true, 
    "include": [
    ],
    "exclude": [

    ]
}

First up - well done! I like this very much and thanks for TypeStrong/ts-loader#537

However, I've found an issue when testing locally. I switched to use fork-ts-checker and deliberately broke the test code. I saw type errors and my tests failed. Great. Then I made some changes to my src code. The tests still failed. Great. Then I fixed the test code, the tests passed again. Awesome. Then I tweaked the src code and noticed the build was still reporting the type errors from when I deliberately broke the test. Nothing I do manages to let fork-ts-checker in on the news that the type error is gone. 😢

I'm guessing this is something to do with having my tests running in a separate process from my webpack build. My setup was based on this:

https://github.com/TypeStrong/ts-loader/tree/master/examples/webpack2-gulp-react-flux-babel-karma

with:

new ForkTsCheckerWebpackPlugin({
      watch: ['./src', './test'] // optional but improves performance (less stat calls)
})

Do you think if this an issue of my setup or is this a problem with fork-ts-checker? I'd be interested to see a setup as above tweaked to use fork-ts-checked in the correct manner assuming this is user error.

I just upgraded my dependencies, and it now display this stacktrace.

/usr/src/app/node_modules/fork-ts-checker-webpack-plugin/lib/service.js:30
    throw error;
    ^

TypeError: lint.getRuleSeverity is not a function
    at NormalizedMessage.createFromLint (/usr/src/app/node_modules/fork-ts-checker-webpack-plugin/lib/NormalizedMessage.js:42:20)
    at Array.map (native)
    at IncrementalChecker.getLints (/usr/src/app/node_modules/fork-ts-checker-webpack-plugin/lib/IncrementalChecker.js:187:11)
    at run (/usr/src/app/node_modules/fork-ts-checker-webpack-plugin/lib/service.js:23:23)
    at process.<anonymous> (/usr/src/app/node_modules/fork-ts-checker-webpack-plugin/lib/service.js:47:3)
    at emitTwo (events.js:106:13)
    at process.emit (events.js:191:7)
    at process.nextTick (internal/child_process.js:753:12)
    at _combinedTickCallback (internal/process/next_tick.js:73:7)
    at process._tickCallback (internal/process/next_tick.js:104:9)

Hey Everyone,

Would it be possible to add some means to configure the typescript options in JavaScript rather than loading them from tsconfig.json? We have many builds that require different setup - for instance one build shouldn't build unit tests, while another should. One build should resolve a particular module using a generated d.ts file, while another should use the actual source code of that module. On top of that, we have about ten apps that we develop, so this adds up very quickly, leading to a myriad of tsconfig.json files just to configure this one plugin.

If we could specify the typescript options (compilerOptions and files/include in particular) directly in webpack.config.js, none of this would be necessary and the whole process would be much simpler.

The plugin crashed right after rebuilding (in watch mode), with below message

/~/node_modules/fork-ts-checker-webpack-plugin/lib/index.js:323
            var elapsed = Math.round(_this.elapsed[0] * 1E9 + _this.elapsed[1]);
                                                  ^

TypeError: Cannot read property '0' of undefined
    at ForkTsCheckerWebpackPlugin.doneCallback (~node_modules/fork-ts-checker-webpack-plugin/lib/index.js:323:51)
    at ForkTsCheckerWebpackPlugin.handleServiceMessage (/~/node_modules/fork-ts-checker-webpack-plugin/lib/index.js:273:52)
    at ChildProcess.<anonymous> (/Users/rok/GitHub/sinicompany/closer-www/node_modules/fork-ts-checker-webpack-plugin/lib/index.js:231:70)
    at emitTwo (events.js:126:13)
    at ChildProcess.emit (events.js:214:7)
    at emit (internal/child_process.js:772:12)
    at _combinedTickCallback (internal/process/next_tick.js:141:11)
    at process._tickDomainCallback (internal/process/next_tick.js:218:9)

version

webpack 3.8.1
webpack-dev-server 2.9.4
fork-ts-checker-plugin 0.2.9
typescirpt 2.6.1
tslint 5.8.0
tslint-microsoft-contrib 5.0.1

options

fork-ts-checker-plugin

{
  "tsconfig": "../tsconfig.json",
  "tslint": "../tslint.json",
  "checkSyntacticErrors": true,
}

tsconfig

{
  "compilerOptions": {
    "sourceMap": true,
    "target": "es5",
    "jsx": "react",
    "module": "esnext",
    "moduleResolution": "node",
    "allowJs": false,
    "importHelpers": true,
    "emitDecoratorMetadata": false,
    "experimentalDecorators": true,
    "forceConsistentCasingInFileNames": true,
    "downlevelIteration": true,
    "pretty": true,
    "declaration": false,
    "noUnusedLocals": true,
    "noUnusedParameters": false,
    "noImplicitAny": false,
    "noImplicitReturns": false,
    "removeComments": false,
    "strictNullChecks": false,
    "outDir": "dist",
    "baseUrl": ".",
    "paths": {
      "*": ["src/*", "*"]
    },
    "lib": [
      "es6",
      "es7",
      "dom"
    ]
  },
  "exclude": [
    "dist",
    "node_modules"
  ]
}

tslint

{
  "rulesDirectory": [
    "node_modules/tslint-microsoft-contrib"
  ],
  ...
}

it works well with [email protected].

I'm using webpack 3, ts-loader, and transpileOnly: true along with this fork-ts-checker-webpack-plugin.

My ts-config.json has "declaration": true, but I don't think I'm getting the type definitions because of transpileOnly: true which makes sense to me, since I didn't allow ts-loader to perform the computation of the types.

If that's the true cause, is there a way to output the definitions computed during this ts-checker phase? And is there a way to further bundle those definitions as webpack already does for the output .js file?

Thanks!

Hi there,

I'm currently investigating if it's possible to replace atl with ts-loader and this plugin in my projects, since the expectable (re-)build performance increase was / is quite impressive.
While testing, I've faced an issue with the emitted errors - they were incomplete.

The playground project I've tested the change on can be found here. The master branch still contains the atl version; I've set up an example for the issue on this branch.

In particular, I've changed this line so that it includes an unused import, which raise a compiler error w.r.t. the project's tsconfig.json.

Expected behavior:
Using yarn build:dev should emit an error like this:

ERROR in [at-loader] ./src/app/i18n/i18n.ts:1:24 
    TS6133: 'IntlShape' is declared but never used.

This is what happens using atl's CheckerPlugin or transpileOnly: false as option for ts-loader.

Actual behavior:
Build works fine, no error is emitted.

Did I miss something on the configuration, or is this a bug?

I have a webpack config written in Typescript (webpack.config.ts; it allows me to use an interface to ensure I'm not misconfiguring webpack). When I try to import fork-ts-checker-webpack-plugin, however, I'm shown an error about missing Typescript definitions.

/Users/andrew/Development/ProjectName/node_modules/ts-node/src/index.ts:307
        throw new TSError(formatDiagnostics(diagnosticList, cwd, ts, lineOffset))
              ^
TSError: ⨯ Unable to compile TypeScript
webpack.config.ts (2,45): Could not find a declaration file for module 'fork-ts-checker-webpack-plugin'. '/Users/andrew/Development/ProjectName/node_modules/fork-ts-checker-webpack-plugin/lib/index.js' implicitly has an 'any' type.
  Try `npm install @types/fork-ts-checker-webpack-plugin` if it exists or add a new declaration (.d.ts) file containing `declare module 'fork-ts-checker-webpack-plugin';` (7016)
    at getOutput (/Users/andrew/Development/ProjectName/node_modules/ts-node/src/index.ts:307:15)
    at /Users/andrew/Development/ProjectName/node_modules/ts-node/src/index.ts:336:16
    at Object.compile (/Users/andrew/Development/ProjectName/node_modules/ts-node/src/index.ts:498:11)
    at Module.m._compile (/Users/andrew/Development/ProjectName/node_modules/ts-node/src/index.ts:392:43)
    at Module._extensions..js (module.js:635:10)
    at Object.require.extensions.(anonymous function) [as .ts] (/Users/andrew/Development/ProjectName/node_modules/ts-node/src/index.ts:395:12)
    at Module.load (module.js:545:32)
    at tryModuleLoad (module.js:508:12)
    at Function.Module._load (module.js:500:3)
    at Module.require (module.js:568:17)

Given that the package is actually written in Typescript, it would be great if you included the type definitions with distributions.

Note that some work appears to be required. I had no problem downloading the package, installing dependencies with yarn and building the package with yarn build. However, when I add "declaration": true, to "compilerOptions" in src/tsconfig.json, yarn build fails unexpectedly:

$ yarn build
yarn run v1.2.0
$ tsc --version && tsc --project "./src"
Version 2.5.2
src/CancellationToken.ts(22,31): error TS4070: Parameter 'json' of public static method from exported class has or is using private name 'CancellationTokenData'.
src/FilesRegister.ts(10,55): error TS4031: Public property 'files' of exported class has or is using private name 'DataShape'.
src/FilesRegister.ts(11,33): error TS4031: Public property 'dataFactory' of exported class has or is using private name 'DataShape'.
src/FilesRegister.ts(13,45): error TS4063: Parameter 'dataFactory' of constructor from exported class has or is using private name 'DataShape'.
src/FilesRegister.ts(39,3): error TS4055: Return type of public method from exported class has or is using private name 'DataShape'.
src/FilesRegister.ts(53,3): error TS4055: Return type of public method from exported class has or is using private name 'DataShape'.
src/FilesRegister.ts(57,48): error TS4073: Parameter 'mutator' of public method from exported class has or is using private name 'DataShape'.
src/IncrementalChecker.ts(61,10): error TS4050: Return type of public static method from exported class has or is using name 'IConfigurationFile' from external module "/Users/andrew/.virtualenvs/tmp-d22ef013cf858b8/fork-ts-checker-webpack-plugin/node_modules/tslint/lib/configuration" but cannot be named.
src/IncrementalChecker.ts(107,10): error TS4050: Return type of public static method from exported class has or is using name 'Linter' from external module "/Users/andrew/.virtualenvs/tmp-d22ef013cf858b8/fork-ts-checker-webpack-plugin/node_modules/tslint/lib/linter" but cannot be named.
src/NormalizedMessage.ts(19,27): error TS4028: Public static property 'TYPE_DIAGNOSTIC' of exported class has or is using private name 'ErrorType'.
src/NormalizedMessage.ts(20,21): error TS4028: Public static property 'TYPE_LINT' of exported class has or is using private name 'ErrorType'.
src/NormalizedMessage.ts(23,26): error TS4028: Public static property 'SEVERITY_ERROR' of exported class has or is using private name 'Severity'.
src/NormalizedMessage.ts(24,28): error TS4028: Public static property 'SEVERITY_WARNING' of exported class has or is using private name 'Severity'.
src/NormalizedMessage.ts(26,9): error TS4031: Public property 'type' of exported class has or is using private name 'ErrorType'.
src/NormalizedMessage.ts(28,13): error TS4031: Public property 'severity' of exported class has or is using private name 'Severity'.
src/NormalizedMessage.ts(34,21): error TS4063: Parameter 'data' of constructor from exported class has or is using private name 'NormalizedMessageJson'.
src/NormalizedMessage.ts(74,31): error TS4070: Parameter 'json' of public static method from exported class has or is using private name 'NormalizedMessageJson'.
src/NormalizedMessage.ts(111,30): error TS4070: Parameter 'typeA' of public static method from exported class has or is using private name 'ErrorType'.
src/NormalizedMessage.ts(111,48): error TS4070: Parameter 'typeB' of public static method from exported class has or is using private name 'ErrorType'.
src/NormalizedMessage.ts(122,39): error TS4070: Parameter 'severityA' of public static method from exported class has or is using private name 'Severity'.
src/NormalizedMessage.ts(122,60): error TS4070: Parameter 'severityB' of public static method from exported class has or is using private name 'Severity'.
src/NormalizedMessage.ts(151,3): error TS4055: Return type of public method from exported class has or is using private name 'NormalizedMessageJson'.
src/index.ts(49,12): error TS4031: Public property 'options' of exported class has or is using private name 'Options'.
src/index.ts(63,14): error TS4031: Public property 'formatter' of exported class has or is using private name 'Formatter'.
src/index.ts(87,24): error TS4063: Parameter 'options' of constructor from exported class has or is using private name 'Options'.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Please note that these errors are show when running TSLint.

$ tslint --project src --type-check

I have a tslint config with the following line:
"pipe-naming": [true, "camelCase", ["gp", "gph"]]

When run with simple tslint command all is fine, however when run with fork-ts-checker-webpack-plugin, I'm getting an error:

"The name of the Pipe decorator of class DateFormatPipe should be named camelCase with prefix gp,gph, however its value is "gpDateFormat"

I think a part of the reason is this line in codelyzer:

https://github.com/mgechev/codelyzer/blob/master/src/pipeNamingRule.ts#L58

args.slice(1) is [['gp', 'gph']] - so array of arrays is joined to be a single 'gp,gph'
http://jsbin.com/mavuxiheni/edit?js,console

which is probably not intended.

Why is tslint command working then? It seems when run with tslint. the rule is executed multiple times with 'gp', 'gph' and 'gp, gph' parameters and that's how the original problem is not appearing.

I don't know how fork-ts-checker-webpack-plugin works under the hood to execute tslint, but apparently there's a difference which causes it to wrongly output the above error.