You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Exactly the project I needed. Though it seems like the directory structure of the source folder (in your example resources/config/* is flattened after processing and isn't respecting the original structure.
This is highly undesirable for my use case where I have a templates folder that contains a dozen sub-folders organized by type and section. A "preserve structure" option would solve this for me.
But maybe more pressing – my templates directory doesn't need to be moved anywhere. Everything that needs to be parsed is already in the location where it belongs.
This presents a problem when the tags used to indicate which strings need to be appended are overwritten in the appending :)
But Iif the delimiter tags were comments instead of template tags, then query strings that needed updating could always be located and updated/amended, and could also be parsed in place (without relocation).
...where your code is only scanning within any open and closing <!-- % --> for href and src – and then finally the ? at the end...updating it according to the manifest.
Even better, after the first run you can update the comment with a time stamp.
So an option for defining the comment or bracket style, together with a requirement and understanding that a ? needs to be at the end of your src or href for the initial parse, and that would do it.
Not easy, I know! But it would be much more broadly usable I think if you can pull it off.
The text was updated successfully, but these errors were encountered:
kerns
changed the title
Feature Request – More Options!
Feature Request : Ability to "Parse In Place" via persisting delimiters (comments!)
Apr 5, 2021
kerns
changed the title
Feature Request : Ability to "Parse In Place" via persisting delimiters (comments!)
Feature Request : Ability to "Parse In Place" via persisting delimiters (comment tags)
Apr 5, 2021
Sorry for the long wait.
Since other people are using this package, I actually wanted to rewrite it and use typescript to provide intelisence, maby somehow make the API more easy to extend (for cases like yours for example), and give it a better name too 😆 , because to be honest right now it's a mess.
Exactly the project I needed. Though it seems like the directory structure of the source folder (in your example
resources/config/*
is flattened after processing and isn't respecting the original structure.This is highly undesirable for my use case where I have a
templates
folder that contains a dozen sub-folders organized by type and section. A "preserve structure" option would solve this for me.But maybe more pressing – my templates directory doesn't need to be moved anywhere. Everything that needs to be parsed is already in the location where it belongs.
This presents a problem when the tags used to indicate which strings need to be appended are overwritten in the appending :)
But Iif the delimiter tags were comments instead of template tags, then query strings that needed updating could always be located and updated/amended, and could also be parsed in place (without relocation).
So for example... instead of
Something like...
...where your code is only scanning within any open and closing
<!-- % -->
forhref
andsrc
– and then finally the?
at the end...updating it according to the manifest.Even better, after the first run you can update the comment with a time stamp.
There are probably better ways to tackle it, but you get the idea. Could also be done with comment tags that don't end up in your html.
So an option for defining the comment or bracket style, together with a requirement and understanding that a
?
needs to be at the end of yoursrc
orhref
for the initial parse, and that would do it.Not easy, I know! But it would be much more broadly usable I think if you can pull it off.
The text was updated successfully, but these errors were encountered: