Browserify build system

[rumblesan]

So these changes move live code lab over to using browserify as a build system, and removing requirejs and grunt.

"But why move to another build system?" you say. Two major reasons,

• There's a lot less config (all of the rjs-init file stuff is gone)
• Coffee script and javascript can coexist more easily (no more build folder and then a dist folder)

Also moving away from grunt and over to npm makes it more obvious what the build system is actually doing. (In my opinion anyway, would like others opinions)

to get up and running for testing it out :-

npm install
npm run devbuild    # build everything to the dist folder. Includes sourcemaps, though that needs testing
npm run serve         # browse to http://localhost:8080

Also includes linting and watch tasks.

Current issues

Tests haven't been sorted out, but should be easier to get working. This involved upgrading to the newest version of CodeMirror, and some of the three.js libraries, so the styling on some things is a bit off. Primarily editor text and the stats widget. Think it's just CSS issues though as some class names have changed.

[davidedc]

OK. I'm doing minor tweaks to the index file and .css since the labels live in their own div, bot hopefully it's minor stuff

[davidedc]

out of curiosity can we do the browserify changes on their own, and then the upgrades to three.js and codemirror?

[rumblesan]

that's actually a fair point. I've just removed the codemirror update, so it's not the existing version. I just modified the source file a bit. short term it's fine, but long term it would be really good to upgrade.

The only issue with the three.js upgrade seems to be that the stats looks slightly different. I'll try to fix that up, and if I cant then I'll revert to the old version. I think the upgrade of the core 3js library actually doesn't affect things that much, but I'll keep investigating

[rumblesan]

right, I've had a quick look at the stats stuff. essentially the new version of the stats widget is bigger than the old one, meaning it doesn't fit neatly in the menu bar. There are three options then.

• move back to the old stats widget and modify it slightly
• remove the stats widget
• roll our own

I don't think that rolling our own, based on the code from the standard 3js one would be too hard. wondering what you think though

[davidedc]

can we get away with fixing the dimensions of the new one?

[rumblesan]

ok, actually it ended up just being easier to revert to the old stats widget and modify it.

At this point, I think this is good to merge. before doing that though, I'm going to have a look at rebasing all the branches you're working on ontop of this to get a feel for how tricky it's going to be. there might be some conflicts and I'd like to know if there's stuff I can do before hand to sort that out

[rumblesan]

ok, so rebasing your branches is a ball ache haha. but I've got it sorted. I have copies of each now that are rebased on top of the changes in this PR. I'll push them up with obvious names, and if you could just double check they work that would be awesome. I don't know if you have more changes you haven't pushed, but if you send them up then I'll get them rebased as necessary. The branches will still need a further rebase so they they're sitting ontop of the merge commit for this PR, but that's easy.

At this point, I think it's actually all good to merge. I'll do a bit more testing though.

[davidedc]

nothing uncommitted. Sorry it was in a bit of a state, I've got a bigger change coming up so it's half hanging.

[rumblesan]

oh the ball ache wasn't your fault, it was because the indentation on almost all the files changed, so git didn't like to do clean merges.

I've found a bug with this PR as well. issues with the noise generation in the math functions. fixing that now

[rumblesan]

right, I think that's the last thing. let me know if you're able to pick up the stuff you're doing off the rebased branches I created. if so then I say we merge this sucker

[davidedc]

I forgot to ask what's the new way to build this now ͡° ͜ʖ ͡°

[rumblesan]

Up in the first message its got the commands. If you look in the package.json file you can see exactly what's getting run

[davidedc]

awesome, on OSX is fine, will play with it on Windows at some point soon.

Interesting conundrum though, the update of three has caused the polygons and balls to look better as there is something that looks like phong shading, you can tell the difference form these:

• http://localhost:8080/#bookmark=webglalmostvoronoiDemo
• http://localhost:8080/#bookmark=monsterblobDemo
• scale 2 ball

Now, this actually looks better but for example I see no strokes (which we have on by defaults)...

Do you know if you changed something special together with three.js or was it some sort of normal upgrade?

(I can take a look if you have no time but worth a question if something stuck out).

If this came because of some special update procedure, I'd prefer to leave that special part out before merging.

If it's part of normal update process, then I'll merge and we need to dig in to see why the strokes are not there and some minor rejigging of a couple of demos...

(wouldn't be the first time that the strokes behaviour changes with an upgrade)

[davidedc]

Ah wait I remember, I turn strokes off when the "normal" material is used, because it wasn't needed. Hmmm seems like I'd need to re-introduce those, let me know if you saw something special in the upgrade though.

[davidedc]

new:

old:

[rumblesan]

I see what you mean about the ball looking different. It's the same with the peg as well. I suspect it is due to the upgrade of three.js, as turning the stroke on and off works as I'd expect. I'm guessing that the material used to cover the objects is just calculating normals by default or something now? Pretty sure we can change it back to the old way if we want. I'll investigate at some point tomorrow.

I think it would actually be pretty cool to be able to turn smooth shapes on and off.

[rumblesan]

right, this is now fixed. turns out that 3js changed the default shading on objects to be smooth shading, and just setting it to be flat shading when we create the materials sorts it out.

There's certainly a few more tweaks that could be made to the build system, but I think they'll get sorted out as we use it more. Docs generation needs to be added back in for example. Hopefully now though the system is much simpler. Let me know if you find anything else

[rumblesan]

oh, also I've rebased the label-text and turtle graphics branches ontop of these changes again. you should just be able to do

git co <branchname>
git reset --hard origin/<branchname>

though remember to git stash any changes you might have before doing that

[davidedc]

Cool. I'll play with it just a bit more and then merge.

I agree we should expose a control to smooth things at some point.

[davidedc]

Ops, just found a bug - https://github.com/davidedc/livecodelab/issues/263