Try loading plugin by name if file not in source-tree

[neochrome]

Hi!
I stumbled upon your project whilst learning more about c64 assembly dev and I really like what you've accomplished - powerful and versatile as KickAss but simple to extend and quick and easy to get going!

While I agree that keeping project specific plugins together with the source is a good idea, I still believe that some kinds of plugins (e.g sid-loading) could benefit from being packaged as separate modules, kinda like the Node stdlib. Also community developed generic modules could be supported.

Anyway, here is an initial take on how to possible support this by introducing a slight change with regards to how plugin paths are currently resolved. What do you think?

Please note that the proposed change will introduce a breaking change in the !use pseudo op to make it's behavior mirror that of Node's require. Plugins referred to with a prefix of either ., ./ or / will still be loaded directly from the file system as today, whereas "plain" names will try to load the plugin from the node_modules folder.

I haven't added test cases for this yet, as I would like to run this by you first and don't really have a good idea on how to ship a test plugin module for inclusion besides actually adding it to node_modules - but that should be solvable.

Regards,
Johan

[nurpax]

Thanks for the suggestion and the PR. I'll need to give this some thought -- I'll reply in more detail later. I'm in the middle of implementing !use to work in the web browser (now it works only on Node) and this may complicate things a little bit.

When you're talking about node_modules, do you mean just accessing files bundled with the c64jasm package, or are you looking for a general npm install c64jasm-sid, !use "c64jasm-sid" as sid style functionality? I think I'm a little bit averse to the latter as I'm not a big fan of hiding fairly simple functionality (sid loading is just one function) behind npm packages. This is assembler coding after all, so it's good for developers to understand how their tools work. (But I think you already know my position on this, given your earlier comments. :))

If you're just looking to bundle things into some stdlib that comes with c64jasm, there may be some other alternatives that'd work in the browser too.

Another approach that I've had in mind would be for c64jasm to support something like project templates, like c64jasm init which would create the boilerplate for you. E.g., just something like:

/src
/src/plugins/c64-stdlib.js  # this would contain the sid loader
/src/main.asm      # entry point
/src/macros.asm  # macros for +basic_start for c64 prgs

This of course is not upgradable in case something needs to change in any of the files generated by init. But if it's really simple stuff (like it tends to be in assembly), that's probably not an issue.

I don't intend to plan for a "c64jasm npm ecosystem of packages" because at least at the moment, c64jasm is a pretty niche project given that c64 developers tend to use KA, ACME and 64tass. If there are only a handful of users, it feels like too much indirection to stick stuff on NPM.

Anyway, hopefully this doesn't feel like I'm trying to shoot your idea down. I'd also like some solution but want to first discuss what'd be a clean and concrete way to implement this.

[nurpax]

Re: !use "foo" vs. !use './foo. We could also introduce something like !use @stdlib/foo` for importing prebuilt packages. I kind of like the current !use path handling as it works the same way as !include. (Fully realizing that Node works differently.)

[neochrome]

Thanks for the suggestion and the PR. I'll need to give this some thought -- I'll reply in more detail later. I'm in the middle of implementing !use to work in the web browser (now it works only on Node) and this may complicate things a little bit.

I can imagine it does ;)

When you're talking about node_modules, do you mean just accessing files bundled with the c64jasm package, or are you looking for a general npm install c64jasm-sid, !use "c64jasm-sid" as sid style functionality?

I was thinking about the `npm install` scenario, mostly to be able to bundle one's own libs as modules in order to avoid copy-pasta for boilerplate code...

I think I'm a little bit averse to the latter as I'm not a big fan of hiding fairly simple functionality (sid loading is just one function) behind npm packages. This is assembler coding after all, so it's good for developers to understand how their tools work. (But I think you already know my position on this, given your earlier comments. :))

...at the same time I hear you on this - not interrested in turning this into some `leftpad` scenario...;)

If you're just looking to bundle things into some stdlib that comes with c64jasm, there may be some other alternatives that'd work in the browser too. Another approach that I've had in mind would be for c64jasm to support something like project templates, like c64jasm init which would create the boilerplate for you. E.g., just something like: /src /src/plugins/c64-stdlib.js # this would contain the sid loader /src/main.asm # entry point /src/macros.asm # macros for +basic_start for c64 prgs This of course is not upgradable in case something needs to change in any of the files generated by init. But if it's really simple stuff (like it tends to be in assembly), that's probably not an issue.

I'm usually a bit hesitant towards autogenerated scaffolding code (for the very reason you mention), but I understand that many are not. Anyway it might be useful, and I should perhaps revisit my stance on this :)

I don't intend to plan for a "c64jasm npm ecosystem of packages" because at least at the moment, c64jasm is a pretty niche project given that c64 developers tend to use KA, ACME and 64tass. If there are only a handful of users, it feels like too much indirection to stick stuff on NPM. Anyway, hopefully this doesn't feel like I'm trying to shoot your idea down. I'd also like some solution but want to first discuss what'd be a clean and *concrete* way to implement this.

Absolutely not, and please don't feel obligated to incorporate my suggestion - it's anyway not ready for prime time yet, and should be discussed (which was my intent with the PR) and cleaned up before coming near your codebase ;) /Johan