Espruino modules packaged as NodeJS modules

One of the reasons for Espruino's creation was the initial 'ease of use' - putting all the tools I could on the chip itself meant that you need very little in the way of software to communicate - in fact just a serial terminal for simple coding. It's unfortunate that with modules, Assembler, minification, etc. the software on the host has actually become quite a bit more complicated - but at least it can still be installed with a few clicks in Chrome...

As a node dev you'll already have node.js installed and will be used to it, so it's easy to just assume it'll be there. I think it'd surprise you how much difficulty people would get in installing it though - especially somewhere like a school where the IT department is very strict about what can and cannot go onto the system.

There's also the issue of platform support - while communication from iPad/etc isn't really used at the moment (with blockly it might get some use in education soon though), a surprising amount of people do use the Web IDE with Chrome OS.

That's not to say we can't use NPM though - there's already some simple support in the Web IDE for NPM modules containing a single file (you mentioned gzip being included, and it's there for unpacking those modules). It could be expanded relatively easily, although obviously it's a shame to reimplement something that already exists (it doesn't have any of the version control stuff at the moment).

As I'd said before I don't think we should move all the modules over to NPM just yet, but at least it doesn't rule it out. The tests are definitely a good idea, and then having a separate repo per module starts to make a lot of sense. While modules that just interface to hardware can't have many meaningful tests, we're starting to get non-hardware libraries like MQTT that would benefit hugely from testing.

I totally agree about EspruinoTools - it really needs to be a module that can easily be used. The way I see it, there are a few separate parts:

Communications

This is really bad at the moment, with several JS files implementing the same interface. You just have to load the one you want.

Ideally we'd have something that could load multiple communication interfaces. You'd call .getPorts() and it'd return a list of all available interfaces - TTYs, network sockets, and audio jacks. You could then connect() to one of them and get the ability to read/write data.

Now here, streams would seem like a good bet. I guess you know more about this than me, but are they something that is implemented on the browser, or are they Node-specific? If they're node-specific I'd guess it's actually a no-go again, but we can just implement write and the data event when running under Chrome and leave it at that.

Code transformation

As I guess you'd noticed, there's sort of a framework where each bit of code places itself inside a global 'Espruino' variable, uses a 'Config' object, and calls addProcessor to register functions that get called on the code at various points.

Basically I had to come up with something that'd run in the browser with no filesystem access, and I wanted to use the code directly (rather than shoving it through browserify) so it could be debugged and changed from within Chrome's debug tools.

UI stuff

The UI is handled the same way - the Web IDE just adds to what EspruinoTools provides.

It's not fantastic, but it's there now, and it works on node and in the browser.

My hope was to actually develop an isolated API layer, wherein I could lift code from EspruinoTools, and build a CLI on top of it (cause that's easy), but publish it as a standalone module which could be extended in any which-way.

This sounds like a good plan. Personally, rather than lifting code out of EspruinoTools, could we not just add an API to the existing EspruinoTools repo and stick it in NPM? It wouldn't be an epic refactor, but would mean that EspruinoTools became something truly useful.

The existing command-line tool could then be modified to use that API and added to NPM too, and everyone's happy?

At some point later on we could refactor what's there, but as you say, at least there would be a consistent API so even if the internals were changed, it didn't matter.