currently localFs eagerly watches the entire subtree under root.
This approach assumes a use-case where the scope of potential interest is limited by the number of file watches the underlying system supports.
for serving nodejs projects with advanced setups (i.e lerna, yarn workspace) it means that the localFs needs to load (and watch) the largest possible scope.
a suitable solution can be a localFs with a different watcher, where files and directories are being watched for changes only after they have been accessed. if there's a need to manage what nodes are being watched and in what level, implementor is advised to share code (extract utils + unit test) with the cacheFs implementation, which solves a similar problem.
currently localFs eagerly watches the entire subtree under root.
This approach assumes a use-case where the scope of potential interest is limited by the number of file watches the underlying system supports.
for serving nodejs projects with advanced setups (i.e lerna, yarn workspace) it means that the localFs needs to load (and watch) the largest possible scope.
a suitable solution can be a localFs with a different watcher, where files and directories are being watched for changes only after they have been accessed. if there's a need to manage what nodes are being watched and in what level, implementor is advised to share code (extract utils + unit test) with the cacheFs implementation, which solves a similar problem.