Open fasiha opened 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.
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 inndarray-ops
since that module effectively exportsaddseq
by something likemodule.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 requiringfs
,stream
,buffer
, and various other node-only modules. Usingbrowser : 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 saysThe 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-transformcwise
and avoid including esprima in the output.