refactor: do not use deno_fs::FileSystem everywhere
#27508
Conversation
There was a problem hiding this comment.
This is so verbose because we don't have conditional compilation for denort (see the todo on line 3). We can improve this over time.
There was a problem hiding this comment.
sys_traits offers an in-memory system, so we can just delete this now.
There was a problem hiding this comment.
I'd like to switch the FileSystem trait back to a type parameter, but first we should split up deno and denort so they're compiled separately.
| @@ -1,12 +1,13 @@ | |||
| // Copyright 2018-2024 the Deno authors. All rights reserved. MIT license. | |||
|
|
|||
| use crate::sys::CliSys; | |||
There was a problem hiding this comment.
Shouldn't this one be under all the other imports? 😏
There was a problem hiding this comment.
Let's merge that other fmt pr 😅
I'll rebase it in a few minutes.
| // todo(dsherret): this is temporary. Instead of using the `FileSystem` trait implementation | ||
| // in the CLI, the CLI should instead create it's own file system using `sys_traits` traits | ||
| // then that can implement the `FileSystem` trait. Then this `FileSystem` trait can stay here | ||
| // for use only for `ext/fs` and not the entire CLI. | ||
| #[derive(Debug, Clone)] | ||
| pub struct FsSysTraitsAdapter(pub FileSystemRc); |
There was a problem hiding this comment.
Looks like deno_core is not upgraded in this PR, not needed anymore?
This changes the cli to mostly use
std::fsviasys_traitsinstead of the implemention ofdeno_fs::FileSystem.This has two benefits:
deno_fscrate.deno_fsfile system abstraction anymore, which does a lot of extra work for things like stat and reading directories.Closes #27464