Split core into npm module

[Shawn Biddle]

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
• 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

[Sean]

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 ***@***.***> 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 <#363>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHxr-TRQCs0JqjQURC4YwEpE4Ii6-8sjks5um_qdgaJpZM4XyRYo> .

[Shawn Biddle]

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

[Shawn Biddle]

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