you might want a command to trigger it from sketchtool
The plugins that I was interested in making were all user-facing and therefore menu-driven, and so the API was designed around this general use case.
sometimes you want the action handler to be in the same file as a "menu" handler
I never considered the co-location reason before, but it does make a lot of sense.
But your implementation will break if Sketch doesn't have an MSDocument as its first document (like a script for example)
One case where it could break is if a user install a plugin that have the same filename as another one
Got it! Thanks for explaining.
I'm wondering if it could be possible to join effort around skpm to bring your good ideas if you're up for it
Absolutely. Happy to help integrate some of these ideas into
the sketch plugin dev community is probably too small to have 2 bundlers competing yet 😃
Sketch Plugin Helper was really just an attempt to see how far to the extreme I could push it in terms of: imposing (opinionated) conventions, aggressively DRY-ing/simplifying things (eg. making the decision to omit
commands for the reason described above; optimising for the general case), and moving common code patterns from userland into the bundler/tool itself. This is so that it becomes a lot quicker to churn out new Sketch plugins, and plugin implementation can be focused on the plugin logic itself as opposed to boilerplate.
With regards to objectives and overall philosophy, I think Sketch Plugin Helper is quite different from
skpm, which as-is seems quite unopinionated (eg. the concept of templates), and leaves more decisions in the hands of the plugin developer.