For bowerfile generators / parsers we can make them accept the contents of files in Hash (if source file is JSON) or String format (otherwise). And return Hash/String too.
For archive extractor passing file in-memory is not efficient, and not testable as well, because archive is binary. I think in such cases the input should be Pathname or internal Path class that inherits from Pathname.
We can't include full contents of extracted files in ArchiveExtractor too for the same reason. I think it's good to return Directory inherited from Path that includes Set of Path. We could call path.read to receive contents of file if we need it for testing.
Resolvers behave similarly to ArchiveExtrator, but the input is URI or String.
As for AssetConverter, both input and output could be Directory. The problem is, they usually work on relative paths to some common directory, and that information is lost when we represent Directory as a Set of absolute paths. I think the best representation in this case would be a set of RelativePath class instances (Path with no absolute location defined).
We could also create MockPath or MockDirectory classes that allow easy mocking of files without creating them in file system.
Those are my thoughts for now. I need to review them. I'm still not sure about representations, especially about relative paths.
It was a big problem for rails-assets.
Example affected classes:
I don't think there's one good solution though.
For bowerfile generators / parsers we can make them accept the contents of files in Hash (if source file is JSON) or String format (otherwise). And return Hash/String too.
For archive extractor passing file in-memory is not efficient, and not testable as well, because archive is binary. I think in such cases the input should be Pathname or internal Path class that inherits from Pathname.
We can't include full contents of extracted files in ArchiveExtractor too for the same reason. I think it's good to return Directory inherited from Path that includes Set of Path. We could call path.read to receive contents of file if we need it for testing.
Resolvers behave similarly to ArchiveExtrator, but the input is URI or String.
As for AssetConverter, both input and output could be Directory. The problem is, they usually work on relative paths to some common directory, and that information is lost when we represent Directory as a Set of absolute paths. I think the best representation in this case would be a set of RelativePath class instances (Path with no absolute location defined).
We could also create MockPath or MockDirectory classes that allow easy mocking of files without creating them in file system.
Those are my thoughts for now. I need to review them. I'm still not sure about representations, especially about relative paths.