addons structure

[konsumer]

I did #117 but things have been a bit undone (some of those demos are not currently working.)

I noticed that examples/others/easings_testbed.js demo broke, because easings.js got moved to src/, and I originally had it at the top of the repo.

If the issue that was meant to solve is not liking code cluttering up the top of the repo, I propose that we move things to addons/, so you can do this:

const easings = require('raylib/addons/easings')

and update the demos to use that.

I also noticed that some of the stuff in text_font_drawtextrec demo are broken, due to DrawTextRec being moved to user-space (in the current raylib demos it's implemented in the demo.) I think this is a mega-useful util, and it should also be added to a helper-lib.

To summarize, I propose these changes:

• move js-space addons to addons/ and make sure they are in package.json files so people can import them
• rename examples/others/ to examples/addons and give the files a prefix to match
• add a wordwrap addon & fix existing demo

[RobLoach]

I think moving easing around would make sense. To get it now, you'd use...

const easings = require('raylib').Easings

[konsumer]

Yep, so the demo/easings I ported doesn't work (because the file used to be in a different place.) That by itself is easy to fix (just change the require) but it leads me to other thoughts about "addons" and other things that are not in the main C raylib.

raylib used to have this stuff in top-level, but as I understand it, moved it into "demo space" so users can more easily configure how it works and see how to do it, if they want to tune it. (see for example wordwrap and easings)

I think we have a few different ways to structure things that aren't directly part of raylib:

1. make a "header" js file, in demos, like they do
2. put the code directly in a demo, so it's not a separate file (easier to see what is a demo and what is a "header")
3. import it into node-raylib (in C or js), so you have them available at top of require('raylib')
4. put them in a separate file you can import (require('raylib/addons/easing')), so you don't have to take all of the "extras" with standard raylib
5. Make separate node-modules like raylib-wordwrap or raylib-easing

• 1 - easy enough to reuse, but clearly "demo space" like original
• 2 - harder to follow (all in one big file) but more atomic, as a demo, no non-demo files in examples/ (as it is now)
• 3 - we can use the original C functions, so easier to "port", and more convenient for end-users, since it's all at the top of "raylib"
• 4 - smaller code if you don't want those "addons", but you can still look at how to do it in js easily (similar to how the original demo functions were helpful in showing how to modify)
• 5 - more module-management, and less transparent how to make your own customized wordrap/easing but maybe that is ok. probly a bit more convenient for user

Overall, I like 4 the best, and I think @twuky agrees, but I could honestly live with all these.

[twuky]

currently i do agree with at least reorganizing things so that not all addons are required by the main package. that way things are at least a little tree-shakeable or can be ignored by a bundler if things were published as seperate packages, it might be worthwhile to change the package to an npm group, so: @raylib/core @raylib/easings etc.

[konsumer]

From experience, orgs are great, but I tend to not like monorepos managed with lerna/workspaces/etc. It can get really confusing. I was just following our current naming with non-org-spaced, but overall, it might be better. Maybe we could move to @raylib/core and publish an empty package to raylib that tells the user what to do (or even just exports @raylib/core which is a dependency?)

[twuky]

i think specifically for this package, working with native addons + a monorepo would be kind of messy in the first place yeah. it really depends on how rlgl/ other c apis will need to be added - whether they can exist in seperate .node builds and still properly interact with the core api

[konsumer]

Here is a simple "warning" package. It would still work, but warn people to move to new package. We can also mark it deprecated on npm, to get a nice big warning at top (with message of our choice.)

raylib-warn.zip

[konsumer]

Some big npm projects even mix a "bare" name (raylib) and org-spaced (@raylib/easing) so if we do want to publish it all separately, that might also be fine.

[RobLoach]

Since easings.h is part of raylib, it would make sense to have it in the core package. Does save on micro-managing versions and packages.

[konsumer]

It's in the examples folder though, not in core. Same with wordwrapping, now. I am down to not have to micro-manage versions & packages, which is partially why I like a separate addons/ dir.

[RobLoach]

Made an extras folder to match raylib's extras folder:

• https://github.com/RobLoach/node-raylib/tree/master/tools/extras
• https://github.com/raysan5/raylib/tree/master/src/extras

Hopefully we could add some of the others in there too :+1:

I'd like to keep the naming conventions the same as C, since they are compiled as straight C files in the global namespace. If you're looking to get a sub-section of the functions, you could do some .map() and .filter() calls...

// Grab the Easing functions
const easings = Object.keys(raylib)
  .filter(name => name.startsWith('Ease'))
  .map(funcName => {
    return { name: funcName, func: raylib[funcName] }
  })

[twuky]

Not sure if I should reopen - but the tools folder isn't tracked in package.json, so users wouldn't have access to the extras folder there. i think it should probably exist in the project root. either way the package.json needs to be updated for it

[konsumer]

Yep, good point. Any "extra" file (something that is not readme.md or referenced in package.json) needs to be added to files.

[RobLoach]

easings.js is part of the generator. It doesn't have to be distributed.

[konsumer]

Ah! I misunderstood. Originally, we were using a separate file (that you could optionally import) but it's in the lib, now. I see, makes sense.