Open BrianLeishman opened 2 years ago
Thank you for bringing up the issue and for the PR!
The suggested fix seems to be harmless, but I'd like to first understand what's going on in more detail.
My mental model was this: If a file is somehow imported and Typescript acknowledges it, such a file must exist, so host.getSourceFile
cannot return undefined
. If it breaks down, could it mean that certain files that Typescript 'sees' may not be discoverable via transitive import or triple slash references? It would ultimately lead to other kind of bugs, where an external module is somehow referenced but tscc is not generating externs for it.
I tried to reproduce the error message but with no avail so far. You've mentioned that events
is included because of grapesjs
, but on my end installing grapesjs
package do not install the events
module, nor does its content reference a node module named events
. The events
's role of replacing native nodejs module in browserify catches my eye though.
Could you please debug a bit on how events
module is referenced from grapesjs
? It'd be helpful if I can reproduce this locally.
It's probably worth mentioning that I think the other thing getting stuck like this was a compiled js file, and bit actually a typescript module.
Tomorrow when I get back to the office I'll try to create a repeatable build using those packages.
With the latest version I'm still getting this error in our project
I traced the error to this package here, that's being reference by a different package we're using, grapesjs. We're not directly including
events
, it's only being included bygrapesjs
.We actually had a different package that we had installed with npm that was also getting this error, but it wasn't being used, so I just removed it, but we still had the issue with the
events
package.grapesjs
is an extern specified in our project,events
is not.Not exactly sure what's happening, but for those files, the
<SourceFileWithInternalAPIs>this.host.getSourceFile(fileName);
line is simply returning "undefined" which stops our compiling, but if I just treat the code as if it can be undefined then everything compiles without problems.We've been running an older fork doing exactly this in production for probably a year or longer now and never noticed any issues, until I tried using this new version again, so we have to fork it for our use once more.