time to split JSRL from JSRL packaging?

[erikyuzwa]

I think we've talked about it on and off before over the past year or so.

Maybe it's time to aim for a directional change @slashman ?

JSRL - this existing repo. JUST contains the JSRL library (as Typescript eventually), easily exportable for importing into any project as-is without fuss. Kinda the way it was originally launched IIRC.

JSRL-forge - (or whatever it's called) another repo that USES JSRL as an import, but designed for the developer or team wishing to pull in the ready-to-publish use of JSRL

might help a lot with maintenance, since you're only either updating the library codebase or the packager / publisher repo.

Maybe give it some thought? Worth a shot?

[slashman]

I think "packaging" is a core aspect of JSRL; it on itself and without too much hassle should allow building a native executable (because this is something highly desired by developers and we can provide that value).

We could always evaluate how this is achieved, and change technologies if needed for the "main" branch (i.e. moving from electron to something else). Additional packagers could be maintained as branches or forks until they replace the official (or even just coexist if we cannot find a reason to replace the official).

In any case, developers that don't care about native packaging can just continue using webpack alone, the downside being a heavier-than-needed node_modules probably.

(Note: We are TypeScript already :))

[erikyuzwa]

Sure - I guess I could see that.

Given how often I'm seeing updates for packagers and their dependencies vs. actual JSRL code, I just figured one way to keep things easier to maintain might be to split them into their own repo projects.

But what you say is fine. Personally I would want to keep everything in the main branch that we want people using vs. other forks or branches for offshoots. But maybe that's also a "just me" thing. :)