-
-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replacing FileSystem::read_to_string()
with typed alternatives
#355
Comments
Would you like to make the changes with Biome integrated? I'm happy to integrate your changes back to |
Yeah, sounds like the requirements for #236 and this are quite similar indeed. I'm indeed first trying it out in Biome to validate the changes. If that works out I'll create a PR 👍 |
Partially completed in #358 The next step is to make package.json and tsconfig.json generic as well. |
For Biome's multi-file analysis efforts, I want to use
oxc-resolver
to resolve arbitrary imports from JS files. However, we'll be persisting an in-memory cache of projects as a whole, and I'd like to use this cache to be used for resolving as well.Great, you say, there's a
FileSystem
trait, and it can be used to implement in-memory file systems, so why not let the cache implementFileSystem
?Two reasons:
package.json
and the likes. ImplementingFileSystem
means that we have the supply the contents of such files as strings. Not impossible, but inefficient.FileSystem::read_to_string()
means that we would need to implement support for reading arbitrary files. But upon closer inspection, it seems that it is only used forpackage.json
andtsconfig.json
files. This makes quite a difference for how we would implement this functionality: arbitrary file content is stored in a different cache than what we call "project layout" information. It would greatly simplify things for us if we only needed to pull information from the latter.My suggestion: Replace
FileSystem::read_to_string()
with two methodsFileSystem::read_package_json()
andFileSystem::read_tsconfig_json()
.I realize these requirements are very Biome-specific, so I understand if we may need to fork and go our own way. But I wanted to ask if there's any interest in following the same approach as Biome for
oxc-resolver
, in which case I'll be happy to contribute back our changes. Happy to hear your thoughts!The text was updated successfully, but these errors were encountered: