brunch can't compile the files if lib option is set in tsconfig.json

[Yaroslav Lapin]

as soon as I set lib in tsconfig.json all of my typescript files are failing to compile with this "helpful" message:

17:57:27 - error: Compiling of File.ts failed. TypeError: Cannot read property 'lineMap' of undefined

as I understand it, that's what we get from brunch trying to set --lib and --noLib at the same time, so to fix it in my project I used the following the the brunch-config.js

module.exports = {
    plugins: {
        brunchTypescript: {
            "lib": undefined,
        }
    }
}

and proper fix would be to do that in the transpile.js

[Thorn Golden]

I don't understand why noLib is being forced in this plugin. I want to target ES6 and use the native Promise (without polyfills) to allow for async/await. But target: "es6" in my tsconfig.json won't work because when Brunch compiles my file, the Typescript compiler doesn't see Promise defined (because it's defined in the ES6 .d.ts file that is being ignored with noLib). This seems like a serious bug to me.

[Paul Medynski]

Same issue for me. I'm targeting ES2017 and Brunch compilation fails because it doesn't know what Promise is. I can't set lib to 'ES2017' in brunch-config.js, so TypeScript barfs anywhere I'm declaring variables, arguments, or return types of Promise.

The offending code in transpile.js is here:

  // We are not returning a sourceFile for lib file when asked by the program,
  // so pass --noLib to avoid reporting a file not found error.
  options.noLib = true;
  // In case it was defined, this is needed to work with noLib above.
  options.lib = undefined;

I don't understand what the comment above noLib is trying to explain. The TypeScript Compiler Options docs don't have much to offer here either.

Can someone explain what the compiler is doing when noLib is false, and why this plugin doesn't support whatever that is?

Thanks!

[Paul Medynski]

After a bunch of digging, I believe the root cause of this problem is in transpile.js here:

  getSourceFile(fileName /* target*/) {
      return fileName === ts.normalizeSlashes(inputFileName) ?
        sourceFile :
        undefined;
  },

The compiler calls the compilerHost's getSourceFile() function for any source files it wants to load, not just the file Brunch is compiling. This is what's causing the loading of the default libs to fail. I fixed it locally by doing this instead:

    getSourceFile(fileName, languageVersion, onError)
    {
      // If the compiler is asking for the file we're compiling, return the
      // sourceFile we prepared above.
      if (fileName === ts.normalizeSlashes(inputFileName))
      {
        return sourceFile;
      }
      // Otherwise, handoff to the default getSourceFile function.
      return defaultGetSourceFile(fileName, languageVersion, onError);
    },

I cached the defaultGetSourceFile by function earlier like this:

  // Create a compilerHost object in order to get some of the default values
  // and functions that aren't exposed otherwise.
  let defaultGetSourceFile, defaultLibPath, defaultLibFilename, newLine;
  {
    const host = ts.createCompilerHost(options);
    defaultGetSourceFile = host.getSourceFile;
    defaultLibPath = host.getDefaultLibLocation();
    defaultLibFilename = host.getDefaultLibFileName(options);
    newLine = host.getNewLine();
  }

As you can guess, I also had to make some changes to a few other functions in the compilerHost in order to get the lib filenames resolving correctly.

I have this all fixed locally. If anyone is interested, I can submit a patch for review and inclusion in the repo.

During my travels, I also noticed that TypeScript expects the values in the lib option to be the actual filenames of the libs (i.e. lib.es2017.d.ts) and not the documented options ('ES2017'). Unfortunately, TS doesn't seem to expose a mapping for those, so I couldn't programatically convert the documented values into the expected filenames.

[Josh Dover]

@paulmedynski Any chance you'd be able to put this patch up into a PR?

[Paul Medynski]

PR #49 contains the fix for this and a few other issues.

[Maxim Syabro]

Is it resolved?