I'm wondering what the behaviour of file imports within a package should be? Specifically when we bundle package the using roc build --bundle would we expect the file imports to be included too? I assume that would only make sense if it was located within the package as a child or something and not some other directory. Or perhaps we do not want to include file imports in packages like this?
The use case I'm thinking about is a package for templating out glue things, and it would be helpful to have templates written in other languages e.g. str.zig and then import the bytes to use in the package. But this doesn't play nicely with the way packages are bundled currently.
Specifically when we bundle package the using
roc build --bundlewould we expect the file imports to be included too?
I think so, otherwise the chance is very high that the package would break without those right?
yeah we definitely should bundle them!
otherwise it'll be a broken bundle :laughing:
Yeah, that’s a good point. I haven’t tested this, we should fix bundle if it doesn’t do this already.
That would be really helpful if we could fix it, for the thing I've been working on.
If it is an arbirtrary import and not a sub directory import, I think we likely should produce an error.
good point
True. I guess someone could sneak an import like this somewhere and steal an arbitrary file from whoever builds the app/package:
import "~/.ssh/id_rsa" as sshKey : Str
so that means both disallowing absolute paths as well as disallowing .. combinations that go too high (probably simpler to disallow .. altogether)
Maybe we allow .. up to main.roc
Not allowing it at all might be too restrictive if you have assets you need to import from multiple levels
Or we make all paths relative to main.roc
I think this is a case where it might be helpful to start with the most restrictive design and then see what problems come up in practice
another possible design is that for bundling we can change the paths
like we make it Just Work
I feel like restricting to the same dir as the file might be a little much because you might not want to mix your assets and code
Richard Feldman said:
another possible design is that for bundling we can change the paths
I don’t think we need that if we allow any path that resolves to something inside the same dir (or subdir) as main.roc as that is the entry point for the bundle.
true
I can't think of a scenario where you'd need to import something higher than main.roc
It would prevent a structure like this:
.git
data/
us.json
gb.json
src/
…
main.roc
but that’s not a big deal I think
At least you can separate your data in its own dir and subpackages/modules can still get to it
an argument for "bundling makes it Just Work automatically" is that it means you can have whatever directory structure you want and still be able to bundle successfully
Yeah, that would be ideal, but I don’t know if that’s a safe default
hm, why wouldn't it be safe?
Agus Zubiaga said:
True. I guess someone could sneak an import like this somewhere and steal an arbitrary file from whoever builds the app/package:
import "~/.ssh/id_rsa" as sshKey : Str
Because of something like this
what I'm imagining is that when bundling, any path that's above main.roc gets rewritten to be some subdirectory
and then also that's where it gets put in the bundle
which should be unobservable to the end consumer of the bundle
Yeah, totally
What I’m saying is that the bundle could end up including an arbitrary file in your system and I don’t know if people would expect that
hm
Like I could “contribute” something to your package and if you don’t review my changes well enough, I could get your ssh key on the next release :sweat_smile:
good point!
ok so we just refuse to bundle in that case
but we support it outside bundling
We could have a CLI argument to opt in into a bigger scope
roc bundle —import-scope=. or something
Richard Feldman said:
but we support it outside bundling
Yeah, that seems important so that check or the language server don’t have to care
I'd rather not get cli args involved in this case
seems like a situation where configuration isn't the answer
Note. With module params, you could pass files down the module tree. So that is an option if we really want to avoid ../
I was wondering if we wanted to restrict file imports to the top level main, app or package level? That might make it easier to see what is happening without needing to inspect every single file.
If the concern is people sneaking new files in or when auditing a package.
I think local is nice personally. Just not higher level than wherever main is.
Last updated: Jun 16 2026 at 16:19 UTC