You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When implementing a FileSystemHost to pass to ts-morph, your readFileSync function must throw FileNotFoundError if the file does not exist. Otherwise project functions like addSourceFileAtPathIfExists will fail. This is because of this code from TransactionalFileSystem#readFileIfExistsSync in @ts-morph/common:
There is a note in the documentation that this function should throw FileNotFoundError which I noticed later, but from what I can tell, FileNotFoundError is not even exported from ts-morph so it's actually impossible to fix this without taking a dependency on @ts-morph/common.
To Reproduce
Implement a FileSystemHost which, when a file doesn't exist on readFileSync, throws any error other than FileNotFoundError. Inject this host into a new Project instance, and then try to add a new source file via project.addSourceFileAtPathIfExists(...).
Expected behavior
This is an implicit contract which FileSystemHost implementations must adhere to but (A) it is not obvious that this contract exists and (B) there seems to be no proper way to adhere to it.
I strongly feel that the runtime dependency on the specific subclass of error being thrown by a FileSystemHost implementation effectively sabotages the inversion of that dependency making it impractical to provide a custom implementation, and should be removed. Short of that, at the very least the issue where this error is apparently not exported correctly should be resolved.
The text was updated successfully, but these errors were encountered:
ryan-palmer-snc
changed the title
Filesystem implementations must throw specific internal Error subclass in order to function properly
Filesystem implementations must throw specific internal Error subclass in order to work, but that subclass is not exported properly
Jul 5, 2024
ryan-palmer-snc
changed the title
Filesystem implementations must throw specific internal Error subclass in order to work, but that subclass is not exported properly
Filesystem implementations must throw specific Error subclass in order to work, but that subclass is not exported properly
Jul 5, 2024
Describe the bug
Version: 23.0.0
When implementing a
FileSystemHost
to pass tots-morph
, yourreadFileSync
function must throwFileNotFoundError
if the file does not exist. Otherwise project functions likeaddSourceFileAtPathIfExists
will fail. This is because of this code from TransactionalFileSystem#readFileIfExistsSync in@ts-morph/common
:There is a note in the documentation that this function should throw
FileNotFoundError
which I noticed later, but from what I can tell,FileNotFoundError
is not even exported fromts-morph
so it's actually impossible to fix this without taking a dependency on@ts-morph/common
.To Reproduce
Implement a
FileSystemHost
which, when a file doesn't exist onreadFileSync
, throws any error other thanFileNotFoundError
. Inject this host into a newProject
instance, and then try to add a new source file viaproject.addSourceFileAtPathIfExists(...)
.Expected behavior
This is an implicit contract which
FileSystemHost
implementations must adhere to but (A) it is not obvious that this contract exists and (B) there seems to be no proper way to adhere to it.I strongly feel that the runtime dependency on the specific subclass of error being thrown by a
FileSystemHost
implementation effectively sabotages the inversion of that dependency making it impractical to provide a custom implementation, and should be removed. Short of that, at the very least the issue where this error is apparently not exported correctly should be resolved.The text was updated successfully, but these errors were encountered: