tsickle: tsickle breaks module names when outDir specified

I’m going to try and be concise so let me know if you need more information. What’s passed to pathToModuleName or emitGoogRequire are strings which are sometimes relative paths, and other times full paths. Why? Well, it looks like TypeScript is doing this, not your code. When TS is taking the input, remember I’m only passing tsc/tsickle one file right now:

node tsickle-master\build\src\main.js src/index.ts

the typescript code (node_modules/typescript/lib/typescript.js) goes through the passed-in code and gathers lists of relevant files. Typically they are stored in arrays of SourceFileObjects, and if you look at the arrays and the SourceFileObject.fileName in each you find:

fileName:"c:/mini/src/classB.ts"
fileName:"c:/mini/src/classA.ts"
fileName:"src/index.ts"

In other words, sometimes fileName is the relative path and other times it resolved to a full path. So this is what TypeScript gathers, and its what you’re using as ES5Processor.file.fileName.

So in typescript.js, (Line 9047 of this file in the TypeScript project)

    function writeFile(host, diagnostics, fileName, data, writeByteOrderMark, sourceFiles) {
        host.writeFile(fileName, data, writeByteOrderMark, function (hostErrorMessage) {
            diagnostics.add(ts.createCompilerDiagnostic(ts.Diagnostics.Could_not_write_file_0_Colon_1, fileName, hostErrorMessage));
        }, sourceFiles);
    }

host.writeFile(fileName - That fileName will be sometimes relative, and sometimes absolute.

Your code, processES5 calls ts.createSourceFile which ultimately uses that code.

So either we must ask the TypeScript project to change how they’re doing this, or the tsickle project must find a way to accomodate both absolute and relative file paths.

Annoyingly, the TypeScript project returns a mixture of absolute and relative file paths even if you pass in all the files! This is because if you have:

  "files": [
    "src/index.ts",
    "src/classA.ts",
    "src/classB.ts"
  ]

TypeScript starts by looking inside of the first file, and looks at all the files it references to build its list of fileNames, so it ends up with:

"c:/mini/src/classB.ts" // got this by looking at index.ts
"c:/mini/src/classA.ts" // got this by looking at index.ts
"src/index.ts" // got this because it was specified

Presumably, “src/classA.ts” isn’t here because by the time it was ready to process the second relative file, it already found it (as an absolute reference) by searching through index.ts.

I hope this has been helpful. Unfortunately being myself a simple JavaScript farmer, I am not the right person to determine where and how tsickle may need to change to accommodate both relative and absolute file paths.

I am seeing the same problems in one of my projects using master branch of tsickle, both with Typescript 2.4.2 and 2.5.3 on Ubuntu 14.04. (Not using angular.)

• Some files are not processed completely by tsickle, missing closure types, etc.
• Module names are sometimes emitted with relative paths and sometimes with absolute paths.

Got no combination working by playing with different combinations of outDir, baseUrl, etc.

After some debugging I found that toClosureJS() (main.ts:124) recevied a list of relative file paths. Independent of the outDir/baseUrl settings in tsconfig.json, they were always relative to CWD. However, shouldSkipTsickleProcessing() (main.ts:130) received a mixed list of absolute and relative paths, so I tried to always work with relative paths by changing the implementation to:

shouldSkipTsickleProcessing: (fileName: string) => {
      if (fileName.indexOf(process.cwd()) === 0) {
        fileName = fileName.slice(process.cwd().length + 1);
      }
      return fileNames.indexOf(fileName) === -1;
    }

And now all files were processed by tsickle, still with broken module names.

For the broken module names, I looked at pathToModuleName() in cli_support.ts. I found that “context” that is used to resolve the relative “fileName” sent to this function are one of these:

• absolute path to a TS file: “/full/path/to/project/src/SomeFile.ts”,
• relative path to a TS file (relative CWD): “src/AnotherFile.ts”
• relative path to a JS file (relative CWD): “build/SomeFile.js”

Just before generating the moduleName in cli_support.ts I added

....
  if (fileName.indexOf(process.cwd()) === 0) {
    fileName = fileName.slice(process.cwd().length + 1);
  }

  // Replace characters not supported by goog.module.
  const moduleName =
      fileName.replace(/\/|\\/g, '.').replace(/^[^a-zA-Z_$]/, '_').replace(/[^a-zA-Z0-9._$]/g, '_');

  return moduleName;
}

Now all module names are correct and it generated 100% closure typed output while all bazel tests still passes. As the same method pathToModuleName() is used to resolve source TS files and built JS files, I am not sure how this can work at all when configuring “outDir” to point to anything else than the src directory.

If pathToModuleName() could also get the values of outDir and baseUrl, etc. it could use those to map to the correct module id. I don’t have time to play with that though.

I am not that familiar with the code base yest, so not sure if this is the way to go, or if there are better places of handling paths. Not sure yet if relative paths are always relative current working directory or if we can get this from tsc somehow?

I’m also experiencing problems with absolute paths, however for me it’s the goog.forwardDeclare() rather than the goog.require(), I’m utterly unable to avoid it no matter what options or setup I use. I’m on Windows 10 too. And I’m also using the --typed argument for tsickle.

src/main.ts

import {foo} from './foo';

function main() {
  foo();
}

src/foo.ts

export function foo() {
  console.log('foo');
}

Output (main.js):

goog.module('src.main'); exports = {}; var module = {id: 'src/main.js'};
exports.__esModule = true;
var foo_1 = goog.require('src.foo');
var tsickle_forward_declare_1 = goog.forwardDeclare('C_.Users.username.repos.typescripttest.src.foo');
function main() {
    foo_1.foo();
}

But the Closure Compiler refuses to so swallow it, reporting on the forwardDeclare “Required namespace (path) never defined.”

As you can see, I have no file named index.ts, I can’t switch between absolute or relative paths by using “outDir” like b-strauss is reporting, it doesn’t matter if I feed in foo.ts in before main.ts like simonsarris is reporting, I tried compiling tsickle from Github rather than running the NPM verison like orenmizr suggested but there was no difference.

Interestingly enough if I just manually delete the offending line and feed both .js files to the Closure Compiler it compiles it just fine.

There was an upgrade to TypeScript 2.3.1 recently. Maybe the TS paths are always relative now.

@simonsarris could you wait until I’m done testing before you close this?

Pardon my ignorance, but how can I install it from GitHub?

npm install angular/tsickle and npm install https://github.com/angular/tsickle.git

seem to fail.

npm ERR! enoent ENOENT: no such file or directory, chmod 'C:\mini\node_modules\tsickle\build\src\main.js'

Is there a guide for building tsickle from source?