A glsl shader loader for webpack, includes support for nested imports, allowing for smart code reuse among more complex shader implementations. The shader is returned as a string.

npm install --save-dev navinfo-webpack-glsl-loader

N.B. As noted in the webpack documentation, you should avoid using this and use the configuration method in the next section.

require('navinfo-webpack-glsl-loader!./my-lovely-shader.glsl');

{
    module: {
        loaders: [
            {
                test: /\.(vs|fs|glsl)$/,
                loader: 'navinfo-webpack-glsl-loader'
            }
        ]
    }
}

and then

require('./my-lovely-shader.glsl');

You can also define the module extension bind on the command line if you are not using a configuration file (you probably should be though).

webpack --module-bind 'glsl=navinfo-webpack-glsl'

This loader supports an import syntax to allow you to maximise your code reuse and keep those shaders DRY. This syntax is very similar to that of SASS.

Example project structure:

src/
---- js/
---- ---- main.js
---- glsl/
---- ---- includes/
---- ---- ---- perlin-noise.glsl
---- ---- fragment.glsl

If I require my fragment shader inside main.js:

var shader = require('../glsl/fragment.glsl');

I can have that shader include other .glsl files inline, like so:

@import ./includes/perlin-noise.glsl;

N.B. all imports within .glsl files include the file extension and are relative to the file doing the importing.

Imported files are parsed for @import statements as well, so you can nest imports as deep as you'd like (although, you should probably rethink your shader if you require any more than 2 levels).

Imported files are inserted directly into the source file in place of the @import statement and no special handling or error checking is provided. So, if you get syntax errors, please first check that shader works as one contiguous file before raising an issue.

• Deduplicate imports, to prevent code clobbering and conflicts at runtime