this was in scrunkly 1 and i'd like to bring it back, however in a much more customizable way - letting you define your own filesystem interface if io is not available. my current idea is to introduce a function like scrunkly.fileReadFunction that lets you set a function that takes in a filename and outputs its contents, by default set to something similar to io.read:
scrunkly.fileReadFunction(function(path)
local contents = io.read(path, '*all')
return contents
end)
however this introduces the issue of relative paths - eg. if file 1 wants folder/2.scrunkly and file 2 wants folder/3.scrunkly, you'd expect going to the file 3.scrunkly to work in 2, however scrunkly has no way to know where from a file is loaded currently
my current idea for this is to make an alternative to scrunkly.build (scrunkly.buildFile?) that provides the path implicitly, and make scrunkly.build error if a path is not provided (or disallow access to goto [filename]
this also opens up path traversal exploits, however - it would also be good to prevent scrunkly from accessing files above the project structure
additionally, it would be nice to pre-emptively build every filename that's mentioned in goto [filename] for performance and runtime safety reasons
this is a complicated mess, but would be a massive improvement to working with scrunkly imo
this was in scrunkly 1 and i'd like to bring it back, however in a much more customizable way - letting you define your own filesystem interface if
iois not available. my current idea is to introduce a function likescrunkly.fileReadFunctionthat lets you set a function that takes in a filename and outputs its contents, by default set to something similar toio.read:however this introduces the issue of relative paths - eg. if file 1 wants
folder/2.scrunklyand file 2 wantsfolder/3.scrunkly, you'd expect going to the file3.scrunklyto work in 2, howeverscrunklyhas no way to know where from a file is loaded currentlymy current idea for this is to make an alternative to
scrunkly.build(scrunkly.buildFile?) that provides the path implicitly, and makescrunkly.builderror if a path is not provided (or disallow access togoto [filename]this also opens up path traversal exploits, however - it would also be good to prevent scrunkly from accessing files above the project structure
additionally, it would be nice to pre-emptively build every filename that's mentioned in
goto [filename]for performance and runtime safety reasonsthis is a complicated mess, but would be a massive improvement to working with scrunkly imo