Gatsby must be installed as a dependency of site

[KyleAMathews]

Globals are bad.

So Gatsby shouldn't do its special sauce in the globally installed version. Instead users should install Gatsby as a dependency of their site and then the globally installed version of Gatsby (if someone chooses to use it) would then run the locally installed bin scripts.

This would simplify long-term maintenance of sites as older sites could keep using older versions of Gatsby without worrying about having to upgrade them when you upgrade the global version of Gatsby.

Also there's occasionally weirdness around having Webpack/Babel load modules from the global Gatsby (this is actually the reason Gatsby is on Babel 5 as when I tried upgrading to Babel 6, I ran into some odd errors that I'm pretty sure will be fixed once this bug is solved).

[gesposito]

Are you suggesting to have Gatsby as a npm dependency of starter projects so it runs locally from node_modules/gatsby/bin?

[KyleAMathews]

@gesposito people could use Gatsby that way, clone a starter and npm install, but I think it'll still be convenient to install Gatsby globally and run gatsby new to get started. But people will have the choice and in either case, the code that is run will be run from node_modules/.bin/gatsby.

[scottnonnenberg]

Using package.json scripts, you won't even need the global gatsby CLI. You can use the binary provided by the development dependency.

[KyleAMathews]

@scottnonnenberg yeah that's the ideal. Naive of me to have ever done it otherwise. It shouldn't be too much work to switch things over I think. Main thing is to add Gatsby as a dependency to the starters + make the global gatsby defer to the local version when one is detected.

[bartekus]

It was probably the most sensible way at the time when you were developing it Kyle, so it's not naive but rather your best shot with what you had to work with. That being said there is also factory option, which might not be most sensible but here is how it work: Gatsby acts as the factory and installs to /gatsby then all starters go to /gatsby/dev/. Now this might not be most popular way but it would allow to completely decouple starters from gatsby while also allowing a deeper optimization from gatsby level. Just my 2 cents here.

[KyleAMathews]

@bartekus thanks :)

Are you describing something similar to #20?

[bartekus]

Indeed @KyleAMathews, the concept pretty much fits what I'm describing and the way to do it would be to mimic webpack-dev-server; where you start from a fixed point loaded into virtual environment which then gets mutated into the state that can be compiled and optimized into the final state. This would in an essence allow almost unlimited flexibility while providing a degree of optimization that currently only purpose build developments allow.

[bartekus]

In a way, Structor could be also be integrated to assist in this 'metamorphosis' further lowering the entry level to Gatsby by allowing GUI based visual manipulations while still staying as close to code structure level necessery to achieve best optimization. Certainly this would be great feature and by extend an enflaming benefit to less technologically inclined parties such graphical designers and artists in general.

[KyleAMathews]

Fixed in #217