Userscripts local import/exports

[quoid]

Allow users to import other locally managed userscripts as dependencies, related #80

[quoid]

@CalmBit

it would be interesting to have a @require analogue that, by default, only responds to file:// URIs. It may make it easier to include things like script dependencies that would otherwise clutter the userscript interface.

I can see why dependencies could clutter the UI. I think we can figure out a way to handle this. I am not keen on giving the app universal file system access as the app sandbox is a requirement for the app store and other reasons. I do think there are viable options, like giving the user the ability to toggles dependencies in the UI, so that they still have a way to edit them in the editor if needed. Also, there is the option of checking the dependency file path on save and if it is outside the current security scope bookmark, create a new one. However could create issues if the ability to edit the dependency in the editor is still desired - the app would need to search all of these different file locations for the dependencies and then bring them into the sidebar on load.

Alternatively, perhaps as a compromise towards a more "universal" approach (i.e. if @require was ever to be implemented for compatibility), the plugin could do something like confirm with the user that the dependency the script requires should be downloaded/queried? Just spitballing this idea here in case it makes any sense or helps to formalize a better system for those kinds of remote dependencies.

This sound like a viable option for when require is implemented, however I am leaning towards the dependency system having unique keys - not dead set on it, just leaning there.

I think the import/export system needs more thought before implementation. If you'd like to help with the feature planning, that would be appreciated. There's a beta build with the @import / @export system now, I will be sending invites out today. Currently there's no hiding of dependencies.

[CalmBit]

A decluttering system, in retrospect, makes much more sense than file:// descriptors, haha. I would love to see that as an option.

This sound like a viable option for when require is implemented, however I am leaning towards the dependency system having unique keys - not dead set on it, just leaning there.

Unique keys as in not being called @require? Sorry, just don't know what's meant by keys here 😅

(I'll try the beta tonight - thank you again for your hard work and quick responses!)

[quoid]

@CalmBit

Unique keys as in not being called @require? Sorry, just don't know what's meant by keys here 😅

Yeah that's what I was thinking. Keep the @require key as it "normally" works and add new ones for the new functionality.