Update to use ES2015 syntax and modules #249
Conversation
This commit doesn’t include an update to the modules system, nor does it update the build system so build-min is broken for the moment.
Gets the min build working again, compiles for non-es2015 compatible environments
Also switched modules from exporting classes full of static methods to exporting collections of loose functions because <type>.length was giving me way too many problems! (It’s apparently a default, readonly property of all classes.) In any case, we seem to be working everywhere now! All tests pass, and built files work well in the browser. :)
Code by @mreinstein, I’ve just rebased it onto my modules changes.
Original fix by @guoyiteng
Originally implemented by @jwu, I’ve just rebased it on top of the modules change.
package.json
Outdated
| @@ -1,7 +1,7 @@ | |||
| { | |||
| "name": "gl-matrix", | |||
| "description": "Javascript Matrix and Vector library for High Performance WebGL apps", | |||
| "version": "2.3.2", | |||
| "version": "2.4.0", | |||
| "main": "src/gl-matrix.js", | |||
There was a problem hiding this comment.
I like the pattern of the "main" entry being the dist/ built file -- this lets others import via node or webpack/browserify still, but not need to assume any sort of ES support (and even if they use babel, they'd need to make sure that they have the same babel configs as you, although limited to the es2015 preset, less of an issue).
An importer would still need the same build environment as the project however if someone is only importing per module (gl-matrix/src/gl-matrix/mat3 vs gl-matrix), but that's the cost to them for selectively importing.
Any reason against using "main": "dist/gl-matrix.js",?
|
I don't see why not. Thanks for pointing this out! I'll make the change in the next day or so. |
|
I agree with |
|
@toji thanks for the update, much appreciated! Looks like some really great changes. A little sad to see browserify go. But webpack is still an improvement. 👍
I'm wondering if the maintenance burden could be significantly eased for this project by pulling in all of the modules hosted on stackgl, which split these units out into individual modules? For example, https://www.npmjs.com/package/gl-vec3 Apologies if this has already come up and been decided against or is infeasible. Lately I've been lamenting that as great as the npm ecosystem is we have 164 different representatations for simple math contructs like vectors and matrices. stackgl/gl-mat3#1 |
|
@mreinstein I think split/miniature packages are the unfortunate consequence of tools not able to pull in parts of a package which was indeed not possible before ES6 modules and that it actually increases maintenance burden. https://github.com/rollup/rollup showed that with proper use of ES6 modules there is no longer a need to split a library into multiple packages. AFAIK, webpack also supports this as of version 3 (see https://medium.com/webpack/webpack-3-official-release-15fd2dd8f07b). |
I wouldn't say it's unfortunate. :) But I'd like to avoid starting a flame war over tiny modules vs larger utility modules. Neither camp is right or wrong, it's just opinion. If you are in the camp of people that like small independent units that do less things, you could use the stackgl variants. If you want more of a fully contained vector/math grab bag, |
|
Updated "main" and "module" as suggested, thanks!
Technically browserify was never here. :) I tried it out because I had used a browserify-based workflow in some of my other code that uses modules, but there were some quirks about how it handled this project that I was less enthusiastic about. Fortunately webpack still does the trick with a dose of babel on the side.
I don't think I can do anything to actively help that. :) There will never be the "one true math lib" even if vector and matrix math become part of the JS core. Everyone has different needs. That's why I made glMatrix in the first place, because at the time nothing else suited my needs. Selfishly, that's why I'm making this update now, because I want to start using modules more consistently in my other code. The fact that y'all find this library useful too is just a bonus. 😉 |
@toji I think maybe there's some confusion; I'm not advocating for one true math lib. What I'm lamenting is that even within the subset of people that think lodash is a good example: it is a utility belt with a bunch of useful functions in it. If you want the full grab bag, you can just Perhaps it's naive, but could |
Pushing this as a pull request in case anyone wants to comment on it before I merge.
The modules conversion is based very heavily on the work done by @bjornharrtell in #209, so most credit goes his way! For the record I initially tried to do the conversion by using ES2015 classes with static methods. (So
class vec3 { static create() { ... } }) but it turns out that the<vec>.length()functions screwed it up because the class types have a default, read onlylengthattribute anyway. As a result I reverted back to Bjorn's original method of having each module be a collection of loose functions imported withimport * as <type> from "path". I would have preferred the cleanerimport <type> from "path"that the classes would have given us, but oh well. Maybe in a glMatrix v. 3.0 I'll rename thelengthfunction to get around it. ;)Also took the opportunity to manually rebase pull requests #248, #247, #233 into this one to prevent forcing the authors to do that. Should also address #237, #240, #241 and does as much to mitigate #244 as I think this library is likely to do.
Apologies for the slowness of updates! I know there's a lot of other issues still open, and I'll try to get to them as I can, but this is a pretty tough project for me to sink a lot of time into these days. Between work and family I don't have nearly as much time as I used to to maintain personal projects like this one.