Careful checking in you build folder. If there are any native modules, and you are not on the same architecture, everything will explode.

This can be avoided by adding "npm rebuild" to your deployment.

I guess you mean the node_modules folder, where in fact this makes a lot of sense. What OP means is the build folder to which the frontend part of project is compiled.

I've been contemplating just checking in the build folder.

It does feel like a code smell, but it'd make deployment easier.

Our frontend is Javascript, wherein there's no worry about native modules.

Our backend is Python running Pypy, so there's no native code there either.

This was held at the ccrma stage! So many great talks and concerts have been held there. I have used that room to stream phish shows and watch cabin in the woods in 5.1 :D

If you are in the bay area you should definitely go check out one of the events, they are all free and open to the public.

--> https://ccrma.stanford.edu/

You can easily refer to a version by specifying it via hash

some-user/some-module#1.0.0

Now this is not very robust, as it does not manually incriment semver. That being said a module it not a git repo. There are pre-publish hooks that can be used to execute scripts before publishing. Further, tracking off of git introduces an entirely new set of problems from tracking tar balls. I can see why the team would not be particularly interested in investing time in it.

> Now this is not very robust, as it does not manually incriment semver.

That was the parent's criticism. Other systems do increment semver.

I've been stuck in file watching hell before... CHOKIDAR!!!!!

I actually had a really interesting conversation with Bert Belder about some of the lower level problem with file watching. It came up that perhaps there could be a working group around fixing this issue.

An amazing product! Super excited to see support for more vendors.

I just made a homebrew formula for this and sent in a PR

https://github.com/Homebrew/homebrew/pull/33487

beat me to it although i made a tap instead. but unless i'm mistaken you don't need openssl or libxml2 since osx provides those.

Someone beat me to it too

https://github.com/Homebrew/homebrew/pull/33486

LOL

The first thing I thought after seeing this trending on HN this morning was "damn, maybe I'll finally have an opportunity to submit a formula to Homebrew!".

wow that's awesome! We really appreciate that.

I really appreciate your service. Having it in the command line will save me a ton of time

3.14 / 2.718

App sux too little pixels

Fancy seeing you in a webpack thread :P

Hey t-plane. Famo.us offers a bit more than just matrix 3d transforms, in fact one of the best ways to think about how famo.us handles dom is more of a transport layer. There is no reason that famo.us could not use the same entity pattern and tree to render to webgl, we just have not been focusing on it (yet).

Disclaimer I work at Famo.us

I hear you, man. But, as we know it, famo.us, is all about matrix3d. And I haven't seen a webGL renderer for it yet. On the other hand, three.js added css3d renderer and it works pretty well with their already established webGL approach.

Keep your eyes peeled for the stuff we are going to announce next Wednesday :D

Ok! Webgl and camera support is all we need from it!

hey - so, I checked out the meeting. Didn't really hear anything new - did I miss something?

Good thing you stopped... as that is entirely inaccurate :D

fwiw I am a famo.us employee