Conceptual explanation needed for how internal modules are minified

@Robin,

looks like mentioning modules in a generic way is a bit a mixed fruit salad...

Modules in the various contexts and processes how they came to be shows the different genuine fruit flavors... so to speak...

There are various types of modules: since we are in the JS world, they are visible in the JS context. Their guts and how they came to be varies a lot:

1. Modules residing in the modules folder on the espruino.com site: are JS in two forms - xyz.js and xyz.min.js - latter for performance and footprint reason. On or before publishing the xyz.js, the xyz.min.js is built from the xyz.js. Several tools are available for that job. dump() delivers what you uploaded onto the board.
   
2. A variation of 1 is when providing a url in require(): any responding site can deliver a module just like espruino.com/modules does.
   
3. Modules in the modules folder of your local sandbox of the Espruino IDE follow the same principle as 1. You build the xyz.min.js of the xyz.js and put it there. dump() delivers what you uploaded onto the board.
   
4. Firmware built-in / included modules can - afik - be of two flavors: the plain one, like 1 or 2 in xyz.min.js but already bundled with the firmware, or, for very performing things, pieces of code written in another language - usally C or Assembler - that are wrapped with a js wrapper that allows to talk to these modules in JS. You can do that with your own build. dump() delivers no source but the indication that it is such a module.
   
   

Some (all?) modules - even though built in- still need a require() to be issued to get them into the application accessible context, because loading / intialization / creation of runtime objects has to happen before the modules functions / objects can be used. Some modules are purely SW related and provide processing services / functions, some they provide access and handling of internal hardware, and thru latter also access and handling of externally wired/connected hardware, such as sensors, etc, often also called modules - hardware modules (they may contain software/firmware as well - as any decently intelligent sensor or communication 'device'/module does - but that's not of concern in this context).

The implementation of the require() and the uploader looking for these (nested) requires (and knowledge ab about what the firmware includes decide what to upload. No minification happens on upload of modules... they are dumped the way they are known to the Modules cache. For the application code in the Espruino IDE editor (right side), the IDE can be configured whether to run the code thru a/the minifier or not.

Speaking of objects: everything is (kind) an object - hence allObects ;_), even though some feel more like functions, where others seem to be just data, and some that are actually fully fletched with data and function (state and behavior). Objects can exist as singletons or - with availability of a generally available constructor(s) - as many instances one type or class - or prototype (to be JS specific).

PS: @Robin, I guess I'm not providing any new insight to you in this post... :\ ... (and it is already documented... may be not in a form to make it obvious 'in one page'... That's why I like the combination of Reference info, Forum, Tutorials, Youtube clips, Instructables... all looking at the same thing from various perspectives...).