Emitting directory crashes with non-ts files

[marikaner]

Some context first: I am generating multiple ts based modules like so:

generated/
    module1/
    module2/
    ...

I use one instance of Project with some subdirectories for this. In addition to ts files I am also generating package.json, tsconfig.json, README.md and CHANGELOG.md files.

The generation has been working for a while, now I want to transpile the modules at generation time. For this, I tried using emit on the directory, but ran into some issues telling me that some files could not be found (e. g. the CHANGELOG.md). I would not expect non-ts files to be relevant for emitting, so I suspect that this is a bug in ts-morph?

The solution I came up with is, that I am removing the respective files from the Project instance before emitting.
Now emitting works, but it does not really do what I need it to do. What I want is a dist folder per module where the js and mapping files go. I was able to achieve this by passing outDir to the emit method.
Unfortunately the mapping files reference their original files relative to the project root and not relative to the respective module. Is there a way to achieve this? I don't think that I can configure this kind of behaviour in the tsconfig.json of the project...

Version: 2.1.2

To Reproduce Use emit on directories with non-ts files.

[dsherret]

I use one instance of Project with some subdirectories for this. In addition to ts files I am also generating package.json, tsconfig.json, README.md and CHANGELOG.md files.

Reproduction:

const project = new Project({ useVirtualFileSystem: true });
const file = project.createSourceFile("/file.md", "# Testing");
file.getDirectory().emitSync();

Stack Trace:

Error: Could not find file: '/file.md'.
    at getValidSourceFile (C:\test\node_modules\ts-morph\node_modules\typescript\lib\typescript.js:111577:23)
    at Object.getEmitOutput (C:\test\node_modules\ts-morph\node_modules\typescript\lib\typescript.js:111947:30)
    at LanguageService.getEmitOutput (C:\test\node_modules\ts-morph\dist\compiler\tools\LanguageService.js:253:86)
    at SourceFile.getEmitOutput (C:\test\node_modules\ts-morph\dist\compiler\ast\module\SourceFile.js:531:46)
    at emitDirectory (C:\test\node_modules\ts-morph\dist\fileSystem\Directory.js:281:43)
    at emitDirectory.next (<anonymous>)
    at Directory.emitSync (C:\test\node_modules\ts-morph\dist\fileSystem\Directory.js:262:20)

---

Hmmm... probably best to not add those files to the project in the first place and just write to them using the file system object (project.getFileSystem().writeFile(...);). That said, since these files don't show up in the program and emit is driven by the program, I think it's a bug here that it doesn't ignore them when calling directory.emit()... I could probably just skip any files where languageService.getProgram().getSourceFile(file) == null. I'll fix this.

Map File Issue

Unfortunately the mapping files reference their original files relative to the project root and not relative to the respective module. Is there a way to achieve this?

That's strange... I haven't tried out map files that much, but usually they will be emitted to the same folder and then the specified map file will just be the file name (so relative). What compiler options are you using? I noticed there's a mapRoot option and changing it adds to the path in the source map file, but has no affect on where it's emitted.

Would you be able to open a new issue for this and provide some reproduction steps? Here's some example test code where it does add an absolute path (removing mapRoot fixes it): https://gist.github.com/dsherret/3116172c6b88d7db40db5f6ac6fa955e

Thanks!

[dsherret]

@marikaner the directory emit is fixed in 3.1.0 (released now). I recommend not putting non ts/js files in the project though. Perhaps something could be done to have regular files (and not ts/js source files), but I'm not sure of a good api for that at the moment.

Anyway, if you could follow up on the map file issue and open a new issue when you get a chance that would be awesome. Thanks!

[marikaner]

Great, thank you for taking care so fast (Timeshift FTW). I will try to change our implementation to your recommendataion and I will follow up on the other issue and try to make it less fuzzy. In fact, I guess it is either a feature request or just my own inability to setup a correct config ;)