Add support for a single folder to be referenced in all projects useful for storing utility functions and classes.
Use Case
Phillip is the head designer at a screw driver startup, Screwed Up.
Over time he has created a set of utilities and functions for the plugins he’s worked on. Since plugins can’t share directories he often copies and pastes new functions across multiple directories.
As a tool maker he realizes that tools are based on standards that multiple companies and multiple tool makers refer to. Ensuring that the specification is the same for each vendor ensures that the tools they make work well together.
Manually copying and pasting his changes from one location to numerous locations has been prone to errors and doesn’t make sense in this context. Having a utilities folder that all of his plugins can reference would ensure a higher level of consistency and fulfill a pinnacle of software development that being reuse.
I tend to agree. With a “shared” folder, questions like “which plugin updates what”, versioning issues (version dependencies etc.) would make this very complicated (and also cumbersome for us as developers). Instead, things like npm modules (if you need a specific selection of libraries, you could also include them in a Git repository and use npm to use that repo without having to publish it to npm) etc. Would make things much easier.
Another concern would also be what you did if two plugins used something with the same name, but different functionality. All in all, it is my opinion that dependency management (if needed) should be done when developing and packaging the plugin and not as a native solution (since that would make it only more complicated than it already is)…
Edit: I also have a template which I use for my plugins with the libraries I always use preinstalled. I think that that is a more elegant solution than running into trouble with a system that introduces many problems like the ones mentioned above.
Again: How would you handle two plugins overwriting each other’s shared utilities.js file? I get the idea, but I think it’s not feasible. It only would make matters a lot more complicated (to solve such issues potentially), meaning modules and dependency-management on the developer side are merely much more manageable when looking at the bigger picture.
Here are only a few problems, which I see with this (let util.js be an arbitrary file in this shared folder):
What if two plugins use different util.js shared files?
What if you have a breaking update for an util.js which requires also updating another plugin, which a user doesn’t update (then, plugin A depends on version 0.1 of util.js and plugin B, which might have an update available but didn’t get updated by a user still depends on v1.0 of util.js, meaning one of the plugins necessarily breaks)
How does this get distributed? A security concern could also be that if I can overwrite something, I could inject harmful code into a plugin that’s not even my own (providing a very sneaky backdoor – and for me the possibility to potentially illegally gain data about the usage of other plugins).
What’s the real advantage here? When using something like npm, you’re just one CLI command away from using your library and have version/dependency management already included. With the multiple webpack-templates available for XD plugin development, it’s also incredibly easy to get started with npm for XD plugins…
I’m sorry, but with the concerns mentioned above, for something where I don’t see your concerns with existing solutions, I don’t think that this should get implemented. One could even argue that it’s good practice to resolve dependency management at compilation (or – for plugins – packaging).
In all honesty, I see a lot of concerns and very little to no real benefit here. The concerns like “prone to errors” would – in my opinion – if anything get worse by introducing this due to the issues listed above.
Therefore, I have to voice my opposition here – not only do I not see any benefits with it, but I only see bad sides making plugin development much more complicated here.
PS: If anyone reading this thinks I’m a bit harsh: I’ll state my case in discussions (which – due to our experiences on other websites, can unfortunately sometimes be difficult to interpret as something other than being rude). From direct messages with @Velara, I know that we both have no problems with a civilized, but well-fought discussion. Therefore, me being harsh is only a means to state my opinion (and by no means any offense on a personal level). Thus, also nothing personal should get (mis-)interpreted into my message by anyone …
Ok, so we’re talking about during development only? From what I had previously read, I thought that you meant for this to be “existent” after a release of the plugin as well.
In that case, of course, many of my concerns are invalidated
However, I still don’t think that it’s a good idea since it would mean that developing inside the develop folder would be encouraged. I, however, find this to be unwise for multiple reasons. For instance, this basically means developing things inside a folder controlled by an application. Instead, I think a workflow where one develops the plugin in some project folder (which is one’s own choice) and then install / continously install it with tools like xdpm should be encouraged, since it also adds a layer of protection during development. Also, when build tools such as webpack (with npm packages etc.) get used, this allows testing the compiled version without e.g., the node_modules folder, already stopping potentially wrong assumptions about what’s included in the build (since the version that gets tested and lives in the develop folder is already the “real” version).
That being said, I think the question now is whether it should be encouraged or discouraged to develop directly inside the develop folder. To me (personally), it feels wrong to develop directly inside a “deployment target folder”. Having my full repo (with git, a node_modules folder and everything else) inside an “application-controlled” folder seems odd to me. Therefore, to me this requests feels like encouraging behavior that shouldn’t be encouraged and I (in all honesty) still see no benefits to it. Quite the opposite, in fact: It would add another layer of dependency management to the process (which libraries are handled by npm, which by this shared folder etc.), and dependency management is – in my opinion – already painstaking enough as it is.
Having said that, I will admit that my concerns of course loose their severity with this only being the case during development. Therefore, while I still can’t say I’m in favor of it (for the reasons mentioned above), I will “withdraw” my huge disapproval (with which I would have continued fighting if it had been the way I first though it to be like), since while I wouldn’t find it good for this to be implemented, it also wouldn’t affect me too much, meaning it kind of doesn’t matter to me if this were to get implemented (or at least nothing severe enough that it’s worth fighting against ).
As I’ve said, I haven’t used the develop folder directly since xdpm became available (back then only in the GitHub organization, not even on npm ) during the Beta.
This means that I develop in another folder (where I also have my Git repository as well as all other files that don’t get packaged), and then install it via xdpm install or – during development – xdpm watch.
While I don’t currently use it, about a month ago I still had a hard-drive in the network, meaning I had my project in there and could simaltaniously test it on Mac and on Windows (with both devices having the drive mounted and then just running xdpm watch on both).
All in all, as I’ve mentioned before, I think it isn’t good practice to have a project folder in some application folder. This way, I’m also able to “package” my plugin into a dist folder with webpack and simply use this dist folder with xdpm watch to always have my fully packaged plugin available (since – if I worked directly inside the develop folder, the plugin would have to be on the “root” level for that, which would be less than ideal).
Therefore, I can only encourage working in some sort of “own”, flexible workspace and “deploy” it to XD with tools like xdpm, since it is a lot more comfortable to use in many cases and also means that you can have it in “good” locations for a project (e.g., a drive in a RAID setup where you get automatic backups – I wouldn’t want to loose a plugin )
…