Split core into npm module

shawncplus commented 5 years ago

Main Concept

There is currently a major workflow issue caused by having the core and the example bundles included in one repo. If you download the project and make your own bundles and make changes and commits and you also want to pull down core code changes you have to do a terrible rebase dance step that's very unfriendly.

This isn't exactly a new idea, nor was it originally mine, multiple people have brought it up in the past. My original argument against this was that it makes it very difficult to modify core if you want to. I now consider this to be a very stupid position to have held :grimacing:. There is (or should) never any reason to modify core. Anything that a user would want to change can be accomplished by extending the Ranvier core class and changing the GameState object in ./ranvier to use the custom extension instead.

This project should be split into many different repos:

ranvier (or ranviermud) an NPM module which should be only the core code found in src/
docs the docs/, site/, and resources/ folders
ranvier-starter-kit essentially everything else except for the contents of the bundles folder, needs an install script to optionally download the example bundles
A repo for each of the example bundles (oof)

Required Code Changes

Update ./ranvier and any bundles that are currently directly importing from srcPath to use the ranvier npm module
Any core classes that have hardcoded directories should be updated to be configurable instead. This is pretty simple aside from the Data class which is static.
Lots and lots of doc updates including documenting the workflow for extending core classes with custom functionality
??? - That seems like it'd be it

Pros/Cons

Pro

Removes the core/example update dance
Allows for more control for the Ranvier user over when/how if to update
Allows for Ranvier to update more frequently since people won't be working off the staging branch of core, they'll be working off an npm module
Discourages users of Ranvier from directly modifying core code which has been a huge issue in the past. Seriously, every. single. fork of Ranvier I've ever seen people willy-nilly butcher core classes even though they don't have to
Much cleaner syntax for new script files. Instead of the old style

module.exports = (srcPath) => {
  const Broadcast = require(srcPath + 'Broadcast');
  const Logger = require(srcPath + 'Logger');
  return { /* some object */ };
};

you should be able to do

const { Broadcast, Logger } = require('ranvier');
module.exports = { /* some object */ };

Con

Gonna be a pain in the ass
Depending on how you debug it makes it harder to debug core because it's contained in node_modules
Other things I'm not seeing

seanohue commented 5 years ago

Another possibility is to still use one repo but make it a mono repo similar to lodash-es or many JavaScript libraries and frameworks that allow use of idioms such as require('ranvier/core'); or require('ranvier/bundles/ranvier-combat'); -- I am not sure if this is more work or less than creating and maintaining several repos.

On Sun, Oct 21, 2018, 12:39 AM Shawn Biddle notifications@github.com wrote:

Main Concept

There is currently a major workflow issue caused by having the core and the example bundles included in one repo. If you download the project and make your own bundles and make changes and commits and you also want to pull down core code changes you have to do a terrible rebase dance step that's very unfriendly.

This isn't exactly a new idea, nor was it originally mine, multiple people have brought it up in the past. My original argument against this was that it makes it very difficult to modify core if you want to. I now consider this to be a very stupid position to have held 😬. There is (or should) never any reason to modify core. Anything that a user would want to change can be accomplished by extending the Ranvier core class and changing the GameState object in ./ranvier to use the custom extension instead.

This project should be split into many different repos:

ranvier (or ranviermud) an NPM module which should be only the core code found in src/

docs the docs/, site/, and resources/ folders

ranvier-starter-kit essentially everything else except for the contents of the bundles folder, needs an install script to optionally download the example bundles

A repo for each of the example bundles (oof)

Required Code Changes

Update ./ranvier and any bundles that are currently directly importing from srcPath to use the ranvier npm module

Any core classes that have hardcoded directories should be updated to be configurable instead. This is pretty simple aside from the Data class which is static.

Lots and lots of doc updates including documenting the workflow for extending core classes with custom functionality

??? - That seems like it'd be it

Pros/Cons Pro

Removes the core/example update dance

Allows for more control for the Ranvier user over when/how if to update

Allows for Ranvier to update more frequently since people won't be working off the staging branch of core, they'll be working off an npm module

Discourages users of Ranvier from directly modifying core code which has been a huge issue in the past. Seriously, every. single. fork of Ranvier I've ever seen people willy-nilly butcher core classes even though they don't have to

Con

Gonna be a pain in the ass

???

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/shawncplus/ranviermud/issues/363, or mute the thread https://github.com/notifications/unsubscribe-auth/AHxr-TRQCs0JqjQURC4YwEpE4Ii6-8sjks5um_qdgaJpZM4XyRYo .

shawncplus commented 5 years ago

A monorepo prevents file conflicts but it doesn't prevent the commit/rebase dancing which is the main thing I'm trying to avoid

shawncplus commented 5 years ago

See https://github.com/RanvierMUD/core and the npmified branch in this repo. The work is mostly done. The next step I want to take on is movie all of the ranvier-* bundles into their own repos under the RanvierMUD org then making the bundle-install script act like a starter kit style install step allowing the user to select a bare install or not

RanvierMUD / ranviermud