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
This shouldn't work. The relative path just happens to work because I'm not protecting escaping from the bundle directory. Can you move the common folder to inside the parallel folder? Then use full paths to the file when using dofile. dofile("common/assert.js")
When we use the custom main feature, the bundle root becomes the directory holding the custom main.
...
I just don't want people getting the false idea that reading outside the bundle will continue to work when they zip their app.
Funny story. Today at work we had an incident with the luvit agent. There was a bug where a path had one too many dots ('..' vs '.') and was reading a file outside the bundle root. It passed all the tests since the tests ran in luvi mode, but when the agent was deployed, it crashed.
So my fear of differing behavior causing trouble wasn't unfounded after all.
I'm fine, however, with adding an explicit flag or something that allows overriding the root path. Or maybe we can have it look for a main.js in parent directories and automatically finding the app root.
I'm a little confused about this though. @creationix Is this just about dofile(), or about alls FS access?
I can imagine many applications that will need FS access outside of an app, but you seem to be indicating reading any file.
Consider an application which needs to store external config, what do we do about that? At very least, uv will need to be able to read outside of the bundle, and any likely module system will probably use the uv bindings which in turn will end up having the same effect.
Perhaps we could add a flag which treats a regular set of files as if it were a zip and limit access? Given how the majority of JS applications are written today I really don't think that it should need a flag to act how most users will expect when pointing to regular JS files.
Discuss?
The text was updated successfully, but these errors were encountered:
The fs actions in nucleus are intended only for loading assets bundled with the app (will be inside the binary once compiled and deployed). For normal fs access, you'll be using libuv or whatever bindings.
Keep in mind that these functions are also sync and should only be used during startup like sync require is done in node.
Moving from the discussion in #15
...
I'm a little confused about this though. @creationix Is this just about
dofile()
, or about alls FS access?I can imagine many applications that will need FS access outside of an app, but you seem to be indicating reading any file.
Consider an application which needs to store external config, what do we do about that? At very least,
uv
will need to be able to read outside of the bundle, and any likely module system will probably use theuv
bindings which in turn will end up having the same effect.Perhaps we could add a flag which treats a regular set of files as if it were a zip and limit access? Given how the majority of JS applications are written today I really don't think that it should need a flag to act how most users will expect when pointing to regular JS files.
Discuss?
The text was updated successfully, but these errors were encountered: