Webpack glslify #270
Webpack glslify #270
Conversation
| fragment: './FragmentShader.glsl' | ||
| }); | ||
| var shaders = { | ||
| vertex: glslify('./VertexShader.glsl'), |
There was a problem hiding this comment.
@adnan-wahab can you please fix the spacing?
|
lgtm :D |
|
@adnan-wahab Are the changes to the shader meant to be included as well? |
|
I don't really see how this addresses the issue. While this now supports Webpack, we still rely on the glslify transform, which means we rely on glslify-loader. E.g. how does this address usage via AMD? I thought we were moving away from relying on glslify in library code (and instead moving it into a bundler agnostic build step, like in the previous PR). |
|
If someone is using another module loading paradigm such as AMD they will still be able to use the built version of famous without a problem. This will at least fix support with webpack and I believe jspm. It is enough for us to support our community while we figure out the most graceful way to EOL glslify |
|
@thealphanerd I'm not sure I understand how this is going to support AMD without usage of the global build. The current solution would still require a preprocessing step for those people from my understanding. |
|
People using amd are going to require a preprocessor either way was my
|
|
Hmmmm.... ok. I don't really see why we can't just put the shader in the repo to be honest (other than rather purist reasons), but maybe I'm missing something. Anyways. If that solves the issue... |
|
@michaelobriena |
|
@adnan-wahab Is it because glslify renames the uniforms for some reason? I had that issue, but thought I might be missing something. Still seems kind of a glslify bug to me. If that's the case, we should probably fix that in glslify... |
|
+1 for putting it directly in the repo and dumping glslify Not sure if that's even possible, but it would be great to use grunt/gulp + bower for build and dep management. Right now I find it near impossible to incorporate that type of build because of the glslify. You are left in a state where some dep's are managed through bower and others are through node 😬. I could be completely wrong, but I would love to be able to list famous as a bower dep and then use traditional gulp / grunt. |
|
@jd-carroll We could still publish to bower with the GLSL code built already. This would allow people to make changes to our shader code and use those changes without having to download a different tool to compile the shaders for them. |
|
I think the bower + grunt/gulp use case is very important. Without it, I On Sun, Jun 14, 2015 at 6:56 PM, michaelobriena notifications@github.com
|
|
I very much disagree. We can easily support bower simply by including the standalone in our Aside from this the tooling /module loading pattern of the use is a moot If a developer has a preference, there is nothing stopping them from sticking If a develop has no preference or does not have experience they can use our If you consider that every in production app will have very different What we cam do, and will, is make sure there is nothing in our build that
|
|
@thealphanerd I agree from a conceptual point of view, but I think the truth is that we can easily support a wider range of tool chains by simply checking in the shader code. This seems like a very acceptable cost considering the increase in usability and that our dependency on glslify has been a problem in the past. I think that's a much more flexible solution than forcing people to use the standalone version.
If we do this, I see no reason why we shouldn't also include the bundled shader code.
There have been numerous complains about our dependency on browserify and glslify. IMO we should aim for making less assumptions about the tooling used by the user. Removing the glslify dependency for using the platform is a step in the right direction IMO. |
|
@alexanderGugel while I agree with your points, I respectfully disagree in practice. Our code base makes a few assumptions
This stack allows for us to do some magical things in development, like what we are doing with glslify. It will also support us being able to do something fancy for assertion like you are suggesting in #285 We need to make a higher level decision if we want to rely on AST transformation between development and production. If so, there is no need to check in the GL code. If people want to use our "development" code in production, the only thing stopping them from doing so is their technology stack. If someone chooses to use webpack, then they can either require in our standalone (which will just work), or they can shim the variety of AST manipulations we want to use. There is no disadvantage to using the standalone build, especially as we can include a version that is unminified and includes source maps. There is nothing stopping them from using the development version either, as they can easily rebuild in-between steps. The amount of build systems and tooling stacks has no shortage, webpack, JSPM, systemJS, bower, npm, commonJS, AMD, es6.... etc etc etc We simply cannot support all the edge cases in our development branch, but we can very easily publish a version that is compatible. If we decide that we need our development branch to be a baseline that works in all systems we are effectively giving up the ability to do AST transformations as part of our development process. Perhaps that is preferred... but I think it is super useful and we should be careful about throwing it away |
The browserify build step is what I'm worried about. One of the advantages of #285 IMO is that everything also "just works fine" without the transform.
I completely agree! Relying on glslify by contrast means the user needs to have Node installed when creating custom builds. I think checking in the generated glslify is really not a big deal, especially if it increases usability in some cases. That being said I don't have an extremely strong opinion about that since - as you said - users can always still use the standalone build when in doubt. The only thing that I'm worried about is that we need to special case everything because of glslify (e.g. glslify-loader for Webpack), which is IMO not needed. |
|
@alexanderGugel I think our main goal is to support multiple build tools and this does that. I think moving away from a strict dependency on browserify is a good goal to have but having glslify is great for engine development (which is the point of this repo). If you don't want our tooling, you can use other tools (because of this change) or just use the standalone as Myles mentioned. I don't think it should be the job of our engineers to maintain personal glsl transform tools just because we want to move off of glslify for no real benefit. |
|
landed as e4e0f0f |
|
As a note regarding gulp and browserify, I have a working famous-gulp-seed which with initial testing supports
What I personally think would be a great add for the |
|
@adnan-wahab Do you have a working webpack example? If so, I'm curious to learn from it. If not, I'll have one soon for everyone. (: |
No description provided.