Open Daniel15 opened 8 years ago
Hi @Daniel15
Its a really good point.
We have - until now - tried to have one single file that adjusts its behaviour according to the environment. Its has, for sure, given us some challenges.
It might be a good idea to have two builds - one for Node (with fs access) and a plain one. Do you have any experiences with automated tests for browser-only libraries?
Hi @Daniel15
Would it be possible for you to run https://github.com/agershun/alasql/blob/feature/browserclean/dist/alasql.nofs.js and verify that your other buildsystem that performs static analysis on the dependencies will accept the code without build errors?
Hi @Daniel15
Is it possible for you to try out your setup with https://github.com/agershun/alasql/blob/feature/browserclean/dist/alasql.nofs.js ?
Meteor 1.3 performs static analysis on the packages - so all references to require(...)
and __dirname
is blocking - even if never invoked... so we really need an automated browser build...
The browser build at http://cdn.jsdelivr.net/alasql/latest/alasql.min.js still has references to the
path
andfs
modules, which can result in build errors when trying to use it from another build system that performs static analysis on the dependencies (particularly a build system that runs outside of Node.js). Browser builds should not reference any Node.js-specific modules. This code should be gated out of the browser builds, either by shimming those modules, or just totally omitting that part of the code when performing a browser build. :smile: