scijs / contributing

Contribution guide lines
10 stars 0 forks source link

ES2015 #28

Open fasiha opened 8 years ago

fasiha commented 8 years ago

I’m not really qualified to discuss CommonJS vs ES2015 modules but I recently used a few scijs libs in an ES2015 module with Rollup, and ran into some surprises.

Rollup can’t find the *,*s,*eq,*eq family of functions in ndarray-ops since that module effectively exports addseq by something like module.exports['add' + 'seq'] = .... So Rollup has to be told about these functions: see the relevant rollup.config.js code.

ndarray-unpack, of all things, was causing trouble by somehow requiring fs, stream, buffer, and various other node-only modules. Using browser : true for the rollup-plugin-node-resolve plugin let me get around the issue, but it blew up my final UMD JS file by 100KB (30~ to 140~ KB). I didn’t spend too much time trying to see which module (ndarray-unpack or its deps) was causing this problem.

I see that there are a couple of Rollup plugins to use Browserify transforms, but I couldn’t get them to work, so when I use a scijs library using cwise, Babel gives up and says The code generator has deoptimised the styling of /.../esprima/esprima.js" as it exceeds the max of "100KB". Actually, it was probably this that blew up the output file size 🤔. Anyway, I’d like to figure out how to Browserify-transform cwise and avoid including esprima in the output.

rreusser commented 8 years ago

Thanks for the report. Looks like maybe the ndarray-unpack issues go back to cwise also. Is it possible to add named exports to the module that has them instead of the config in your project? As long as it's non-invasive and not unwieldy, that would be a nice option.

Sounds like the right answer might be to investigate trying to get the transform working with rollup.