Need help to optimize Typescript compiler from someone who understands the Meteor compiler plugin system

permb · June 1, 2020, 12:37pm

The new refapp:meteor-typescript compiler is working great for us but it’s a little slow.

There isn’t much we can do with the actual Typescript compilation - when it looks at all combined Typescript sources and decides which ones need to be rebuilt based on the saved incremental buildinfo - but the part where the transpiled source is sent to Meteor seems unnecessarily slow - Meteor asks for transpiled sources even when the source or hash value have not changed and this causes more compilation downstream (Babel etc).

I think the problem lies in how to properly set hash values in AddJavaScript so that the lazy compilation takes effect but I could be wrong.

So I was hoping that there was someone active in this forum that could help out to tell me how to write the code to be optimal.

Here’s the relevant source code:

github.com

ref-app/meteor-typescript-compiler/blob/9b5dc7e8e2ca910bacb05d216bead0e0ae9d71b7/meteor-typescript-compiler.ts#L270


      this.error(`Nothing emitted for ${inputFilePath}`);
      return;
    }
    const { data, fileName, sourceMap } = emitResult;
    // Write a relative path. Assume each ts(x) file compiles to a .js file
    const path = inputFilePath.replace(/\.tsx?$/, ".js");
    const bare = isBare(inputFile);
    // Compute the hash from the generated data itself since we depend on the typescript incremental compiler
    // to make that cheap to get
    const hash = calculateHash(data);
    inputFile.addJavaScript({ path, bare, hash }, () => {
      // It seems that in order to get Babel processing, we must invoke it ourselves and cannot
      // depend on the ecmascript package to do it for us
      this.withSourceMap = { sourceMap, pathInPackage: inputFilePath };
      const jsData = this.processOneFileForTarget(inputFile, data);
      return jsData;
    });
  } catch (e) {
    this.error(e.message);
  }
}

/Per