rename the CachingCompiler to Filer and add binary file support #54
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a major refactor of the
CachingCompileradded in #51 that adds support for binary files. There's further refinement of the concepts, andFilerwas the best name I could come up with for the role that it plays. It's the primary interface with the filesystem, watching for changes and writing efficiently back to disk, and it compiles files when they change and figures out how to efficiently update the caches in memory and on disk. It's now integrated with both the dev server for serving files and it's used in one-off compilations, not just watch mode. It will also have subscriptions soon to support things like live-reloading CSS. It's basically the heart of the Gro development process, and though we'll likely want to extract concerns out of it and make it more flexible and modular in the future, I'm okay with the high amount of complexity it deals with internally.There's more work to be done to support unbundled development with Svelte, but this gets us much closer.