Conceptual explanation needed for how internal modules are minified

Sat 2021.10.30

Using both the native app and the online WebIDE, even when minification is turned off in settings, an internal module request (as in this instance) is returned minified.

var wifi = require("Wifi");
wifi.connect("2WIRE", {password: "3321205"}, function(err){

Results of dump()

var wifi = {
  "connect": function (a,b,c) {
  var d="";c=c||function(){};void 0!==b.password&&(d=b.password);u(k.CLIEN­T,function(b){if(b)return c(b);f.cmd("AT+CWJAP="+JSON.stringify(a)­+","+JSON.stringify(d)+
"\r\n",2E4,function m(a){if(0<=["WIFI DISCONNECT","WIFI CONNECTED","WIFI GOT IP","+CWJAP:1"].indexOf(a))return m;"OK"!=a?setTimeout(c,0,"WiFi connect failed: "+(a?a:"Timeout")):setTimeout(c,0,null)}­)})
},

From

http://www.espruino.com/Reference#Wifi
I am able to locate the .c source that is used to generate the wrap container
https://github.com/espruino/Espruino/blo­b/master/libs/network/jswrap_wifi.c#L207­

I'm struggling with how the WebIDE is returning minified code, when those options are turned off.

Is it that the internal modules are minified and included within the .hex .elf build, such that accessing them is returned as such, (in this case is there a location of the minified .js source at GitHub?)

or,
Is it that the .js content is run through the Esprima minifier real time when the .connect() (in this instance) function is called,

or, . . . other??

Note: I still haven't been able to run successfully an openOCD session to peek into these files.

@Robin, in the Espruino IDE config you can define what should be loaded when using require(). Is that what you are looking for? ...after all, even a plain .js module file may minified... so you do not have fully control over it.

Sun 2021.10.31

Thank you for responding @allObjects.

Maybe my question should be where is the underlying Http/Wifi Javascript source (or any internal module) and it's corresponding minified resultant code block that is returned to the WebIDE when viewed using dump()?

In comparrison,

Should I load the 'GPS' module that is available as two sources:

http://www.espruino.com/modules/GPS.js
http://www.espruino.com/modules/GPS.min.­js

the WebIDE will (based on settings) fetch the .min.js file first, which when exposed using a browser will show the underlying content when using dump().

var gps = require("GPS");
Serial2.setup(9600,{tx:A2,rx:A3});
 gps = gps.connect(Serial2, function(data) {
 console.log(data);
})

and when viewed using dump()

var gps = {
  "line": "",
  "#online": function (a) {
  var c;if(c="GGA"==a.substr(3,3)){c=a.length;­var d=0;for(let e=1;e<c-3;e++)d^=a.charCodeAt(e);c=parse­Int(a.substr(c-2),16)===d}c&&(a=a.split(­","),c=a[2].indexOf("."),d=a[4].indexOf(­"."),f({time:a[1].substr(0,2)+":"+a[1].s­ubstr(2,2)+":"+a[1].substr(4,2),lat:(par­seInt(a[2].substr(0,c-2),10)+parseFloat(­a[2].substr(c-2))/60)*("S"==a[3]?-1:1),l­on:(parseInt(a[4].substr(0,d-2),10)+pars­eFloat(a[4].substr(d-
2))/60)*("W"==a[5]?-1:1),fix:parseInt(a[­6],10),satellites:parseInt(a[7],10),alti­tude:parseFloat(a[9])}))
}

Comparing the two, it can be seen that function(a) is the same code that resides in the .min.js file in the online modules folder. The human readable corresponding .js file then, may be used to cross reference.

How does one do the same task for the internal modules? (neopixel, wifi, http) etc.
e.g. where is the human readable source and where/how does that become minified such that using dump() reveals the output as in post #1 ?

Sun 2021.10.31

https://github.com/espruino/Espruino/tre­e/master/src

Contains the .c source to generate the mechanics/functionality

https://github.com/espruino/Espruino/tre­e/master/scripts

the logical repository folder name contains the .py build instructions, not .js scripts

https://github.com/espruino/Espruino/blo­b/master/libs/network/jswrap_wifi.c

the metadata describing each of the callable functions

@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...).