Plugsy - plugin development framework

Discussion in 'JS Plugins In Development' started by aethon, Dec 15, 2017.

  1. aethon

    aethon Villager Member

    Messages:
    23
    Likes Received:
    29
    Location:
    Wisconsin
    First Language:
    English
    Primarily Uses:
    RMMV
    Howdy all.

    I've been working on Plugsy, a plugin framework for MV plugin developers that seeks to replace some of the boilerplate plugin code that winds up in basically every MV plugin.

    It's written primarily for use with TypeScript and ES6, but will probably work just fine with vanilla ES5. (You'll need to update the config to build for an older JS target.) A brief overview of some features:
    • automagical data serialization - no more manual save code or property collisions on $gameSystem!
    • declarative plugin commands - no more messing around with the interpreter!
    Some standalone features that are also integrated with the aforementioned ones.
    • shimmer: easy method overwriting - no more obnoxious prototype futzing!
    • tagger: XML-style notetag parsing - no more hand-written regexes!
    • loader: promise-based data loading - no more XMLHttpRequests!
    There isn't any integration testing yet, so I'm not going to claim it'll work perfectly within MV (getting MV running in a server-side environment is a nightmare) but the shimmer, tagger and loader exports are thoroughly tested and should work just fine. Code is on GitHub -- MIT license, so use it for whatever. I'd appreciate a shout-out if you do end up using it, but it's not necessary by any means. Issues and PRs appreciated.

    It's primarily targeted to the more savvy devs at the moment - you'll need NodeJS installed before you can hack on it.

    https://github.com/noahlange/plugsy
     
    #1
    Kaelan, Zeriab, Kvothe and 1 other person like this.
  2. Joy Diamond

    Joy Diamond Talkative Veteran

    Messages:
    135
    Likes Received:
    172
    First Language:
    English
    Primarily Uses:
    RMMV
    Thanks for using github & the MIT License.

    I'll be looking at this, as I am doing a very similar project, also MIT licensed. My main current focus is on:
    • Turn the insanity of JavaScript into a modern programming language & environment.
      • Basically restrict the developer from shooting himself or herself in the foot & wasting hours chasing bugs.
    • Understandable & real class system like all modern programming languages have (instead of the prototype craziness that 99%+ of JavaScript developers do not really understand -- i.e.: causes confused thinking):
      • Real instances
      • Factories, instead of new
      • Composition instead of inheritance (long term focus is interface & traits).
        • Inheritance will be allowed, but will probably be optimized into composition (user option).
      • All class members must be declared properly before use. You may not create random new class members without declaring them first -- it will throw errors at you if you do.
      • In case the above was not clear, the use of '.prototype' is also outlawed. It will throw errors at you if you try to use it.
    • Throw errors on all illegal attribute accesses. I.E.: If you say window.oops, it will throw an error instead of returning undefined.
    • All functions, members, methods, and especially closures, must have a .$name & .$summary member, to make everything super easy to introspect & understand from Developer Console
      • (Only in debug mode, in release mode, these are not created or used)
    • For development, lots of separate *.js files instead of a single js/plugin/*.js file (for release, would combine it back to a single js/plugins/*.js file)
      • Individual *.js files must be small, self documenting (i.e.: see .$name & .summary) -- so can click on their link in Developer tools & quickly see their source code without tons of surrounding distracting other stuff.
    • No use of global variables, everything done via closures (i.e.: imported & documented), so easier to understand code.
    • In debug mode, Proxy everything (so can throw errors on illegal attribute access; also protect 95% of members as immutable.)
    • Allow dynamic reloading of code (which invalidates all previous instances from that code -- partially relying on Proxies to achieve this). This allows changes to reload in 0.1 seconds instead of 10 seconds+.
    • Much cleaner stack traces, easier to debug.
    I think it would be great to have a group of developers support a common set of plugin's together & build out a common code base that makes it 10x easier to develop and understand plugins.
     
    Last edited: Dec 16, 2017
    #2
  3. aethon

    aethon Villager Member

    Messages:
    23
    Likes Received:
    29
    Location:
    Wisconsin
    First Language:
    English
    Primarily Uses:
    RMMV
    You betcha, it's a de-facto standard in the JS dev community, which is my side of the pond.

    I agree on the big-picture. Currently the ES5 MV codebase is kind of a cluster, and I think moving to a more robustly-documented, modern (and IMO, typed via TypeScript) one would help fix a lot of those issues.

    So ES6/TypeScript has Classes, which are sugar for the prototype system. I'm under the impression that most peoples' issues with the prototype system are more an education problem than intrinsic to prototype-based inheritance.

    I feel less positively about this. I think with the ES6 class system, classes make a good deal more sense than factories and more "traditional," Java-esque OOP. SOLID is way better (and idiomatic) for Java or C# than JS.

    I'm slightly more on board with this, but I still think JS is much less well-suited to ECS than other languages, even when you introduce typing. Sure, TS's interfaces will get you part of the way, but even TS has no support for mixins or traits, which'd be a big part of any composition system.

    I don't know that this'd be enforceable in JS. You could proxy everthing, but the perf hit from that would be extraordinary.

    Hmm. I think a proper typing system would obviate the need for many of these. I don't think the console is really the best place to be doing source inspection, apart from trivial logs -- source maps are much more idiomatic in JS, and if you set things up properly you can use the debugger with them.

    Yeah. ES6's module system would make this much more doable -- it's much more oriented toward a modular architecture. Source maps can get you the source code view part.

    Yeah, agreed, the globals are unmaintainable.

    You can make stuff immutable without using Proxies. https://facebook.github.io/immutable-js/ is a great library that allows that.

    Agreed, hot module replacement would be awesome. Webpack has a great API for this: https://webpack.js.org/api/hot-module-replacement, but we'd need to start using a module bundler in order to see any benefit from that.

    Also agreed. Currently, the code quality in the ecosystem is pretty low. Waaaaay too many evals.

    Overall, I agree with a number of your points. But as someone who works professionally in the JS ecosystem, I think some of them are impractical, implementation-wise, for a JS codebase. I've forked a TypeScript conversion of CoreScript that looks really promising. I'll see if I can get it up on Github at some point, would probably be a good starting point.

    One of the greatest strengths of MV, is, despite its many issues, the plugin ecosystem. I think the most important parts of a re-envisioning of Corescript would be (in no particular order) a) maintaining a compatibility layer/plugin for existing plugins, while deprecating things like global access, &c. b) getting some sort of testing suite up and running c) maintaining compatibility with the editor, to the point where an existing project could have CoreScript swapped out and function as expected and d) switching to a module-based architecture.

    Those sound more important to me than moving to a more traditional OOP architecture. If you create an entirely API-incompatible CoreScript re-implementation, absolutely no one is going to use it - in my opinion. People are going to stay where the plugins and the editor are, and so maintaining compatibility with those is critical.
     
    #3
  4. aethon

    aethon Villager Member

    Messages:
    23
    Likes Received:
    29
    Location:
    Wisconsin
    First Language:
    English
    Primarily Uses:
    RMMV
    Howdy! Been a while since I last updated this. Long story short, I've been using it on a handful of plugins and updating it incrementally.

    Among the more interesting new features are a proper XML-based tag parser (and peaceful coexistence with Yanfly tags) and functioning variable persistence. Not the most exciting of releases — it was mostly bugfixes.

    Hopefully this will prove useful to folks in the community. Ping me if you have any questions!
     
    #4

Share This Page