Conduitry/defiler
1
Fork 0
Code Activity

doc updates

Browse source
This commit is contained in:
Conduitry 2017-05-20 14:03:55 -04:00
parent 4d9980e2fd
commit 7e42c2bb02
2 changed files with 5 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

4
API.md
View file

@ -146,9 +146,9 @@ An `origFile` event is emitted when the original version of a physical file has
A `file` event is emitted after all transforms on a file are complete. It's emitted with two arguments: the file's original relative path and the fully transformed `File` instance.
### `deleted(path)`
### `deleted(origPath)`
A `deleted` event is emitted when a watched physical file has been deleted. It's emitted with one argument: the relative `path` to the file.
A `deleted` event is emitted when a watched physical file has been deleted. It's emitted with one argument: the original relative path to the file.
### `error(origPath, file, err)`

4
TODO.md
View file

@ -1,3 +1,5 @@
# TODO
- maybe some sort of way to have parameterized generated files. Not sure how this would look exactly. There could be some files that we want to process in one of two (or more) ways, depending on where they're used from, but we can't tell from the file itself how it should be processed. We could push responsibility for this processing into the transform etc. that needs the processed file, but that doesn't seem ideal, as when one dependency changes that would involve re-processing other unchanged things we've already processed. One case I've run into that would benefit from such a feature is compilation of Svelte components: Looking at the component itself, there's nothing to indicate whether it should be compiled in `ssr` or `dom` mode. Ideally, whichever transform requires a particular version of it could request that (and it would be generated then, or retrieved from a pre-existing cache). It might be best if this were a whole separate third type of thing, apart from physical and generated files
- maybe some sort of way to have parameterized generated files. Not sure how this would look exactly. There could be some files that we want to process in one of two (or more) ways, depending on where they're used from, but we can't tell from the file itself how it should be processed. We could push responsibility for this processing into the transform etc. that needs the processed file, but that doesn't seem ideal, as when one dependency changes that would involve re-processing other unchanged things we've already processed. It might be best if this were a whole separate third type of thing, apart from physical and generated files
- I'm probably leaning away from this being Defiler's responsibility. This is something that can be handled by the consuming project. This 'contextual processing' can be done on-demand, and the values can be cached by storing them directly on the `File` instance. The cache will be automatically invalidated in normal cases, when necessary the instance will already be getting discarded and re-created from the `File` instance for the original file on disk