Break out XLSX Support or release an alasql core

[dmfenton]

Thank you for your awesome work. This is an excellent library.

A huge portion of the code weight is devoted to supporting xlsx. While that may be a big portion of your users, it's not all of them. It would be great if there was a way to do a build without this code. I'm not sure where this stands in your priorities, but it seems like it might be a relatively easy task so I'd like to really advocate for this.

Thanks again and keep up the great work.

[mathiasrw]

This is one of the most important elements: to build the library so you can select what parts you need.

There is work in progress in the feature/plugin_structure branch primary driven by @nickdeis

If you would like to help out that would be really awesome.

[dmfenton]

I'm interested in helping out, but to be honest, your code structure is very very confusing.

[mathiasrw]

It really is :)

That is why nickdeis is working on restructuring it to be small individual modules requiring each other (all his work is placed in https://github.com/agershun/alasql/tree/feature/plugin_structure/ecma6 )

Ill ask him if he can write a short description on how to start contributing

[dmfenton]

That's awesome, thanks!

[nickdeis]

Completely agree. I was going to write a ticket about how we should do plugins. XLSX and XLS were my first target. The vast majority of the alasql codebase works by attaching itself to the global alasql object, so I was trying to organize the codebase to reflect that.

While certainly not elegant, I was thinking a plugin would simply be a function passed through some function (alasql.plugin?) and just do what it needs to do.

Let me see if I can write up an example this week.

I'll try to add README to each directory. Alasql is full of hidden secrets, which is probably a bad thing, but once you get the idea things kind of make sense.

Nice to be working with a fellow DC programmer btw.

[mathiasrw]

Alasql is full of hidden secrets, which is probably a bad thing, but once you get the idea things kind of make sense

:+1:

[dmfenton]

@nickdeis :wave:

Here's an example of how I handle plugins in my project: https://github.com/koopjs/koop/blob/3.0/src/index.js#L155-L166

Perhaps not elegant but it works well in practice.

[nickdeis]

@mathiasrw Do we plan on updating the typescript definition files? If so, the AlaSQLCallback is a little out of date. For the sake of documentation and the plugins, I've added typescript definition files for things under the from, into, and engine namespaces (eg: alasql.from).

I think the best way to approach the XLSX plugin is to have it implement a AlaSQLFrom functional interface, and likewise a ALASQLInto functional interface.

[mathiasrw]

Do we plan on updating the typescript definition files?

Good you point it out.

I have never worked with typescript definition files. I will look into how to get them updated.

[mathiasrw]

I have pushed a new version of the typescript definition: https://github.com/agershun/alasql/blob/develop/dist/alasql.d.ts

@nickdeis would you be so kind to check if its working?

[nickdeis]

It is sort of working: AlasqlCallbacks (cb) typically take three arguments. However, that's enough for me to work with. Should these plugins be build time or run time? I'm leaning toward build time.

EDIT: With a helpful online tool to help people without node/npm of course. I took time to research the viability of this for rollup.

[mathiasrw]

Im in strong favour of build time...

If it will help you if I get the typescript more correct please let me know.

[mathiasrw]

Let me see if I can write up an example this week.

@nickdeis did you ever get to describe with a few lines how to compile / run the new plugin structure ?

[nickdeis]

@mathiasrw Sorry about the delay. This a lot more architectural astronautics than I'm use to. Example: (I don't really care if we keep plugins in separate repos or not). alasql-plugin-xlsx.

I tried to design them to the best of my knowledge on how to write a good plugin, and what other plugin heavy libraries do. All of them have a well defined inversion of control where the plugins are not aware of the parent library.

I will write the core attachment code next.

Tell me what you think

[mathiasrw]

@nickdeis Quick question: How do I testrun the ecma6 structure?

Is it just to (for example) browserify ecma6/global/start.js and then go play with it?

[nickdeis]

Go to a flavor folder gulp Should produce the slim build

Really don't care if you change how this works. I really need to research a smarter way to do a multiple types, multiple plugin build with rollup.

[nickdeis]

@dmfenton + @mathiasrw This plugin might have to get ugly because of some interesting features in the XSLX library. Good thing we are breaking it out as a plugin! I just have to use webpack instead of rollup

[mathiasrw]

@nickdeis nice - thanks...

@dmfenton is this enough to get you started?

Go to a flavor folder gulp Should produce the slim build