Get glslify working with ify-loader

[rreusser]

It seems that opts._flags is empty by default. When this gets passed to glslify@5 that's fine. glslify@6 fails because that causes it to fall into the string output branch. The fix is to simply specify opts._flags = opts._flags || []. That causes it to function as a transform.

Things to do:

• test it
• ensure [] is the proper default for opts._flags. (This seems not particularly important, maybe? It's a default that works fine since it's only relevant when it was unspecified and just needed to be truthy. It could be foo and work just fine, right? But should still check.)
• The glslify output fixture has an extra comma at the end. Is that normal?

I'm not sure it's strictly "correct", but since glslify makes the presence of opts._flags a hard requirement in order for it to function as a transform, it seems reasonable that it's okay to just provide that as a courtesy for all transforms.

cc (and big thanks to) @bpostlethwaite @VeraZab

See also: #5, #7, #9, glslify/glslify#74

[rreusser]

Confirmed working all the way through with plotly.js. Though I never mind a second set of eyes or testing with more versions of webpack. You'll have to hook it up to this particular PR (or just add that flag manually in node_modules/ify-loader/index.js), but with this change, this repo compiles both just fine and produces plotly plots: https://github.com/rreusser/plotly-webpack

[VeraZab]

I can test webpack 1 & 2

[VeraZab]

tested with webpack: 2.7.0 & 1.15.0: works!
with this repo: https://github.com/rreusser/plotly-webpack

[bpostlethwaite]

Thanks @VeraZab and @rreusser. Is this ready to merge?

[bpostlethwaite]

@hughsk did you want to take a look? I'll hold off merging for 3 days to give you some time. We'll test it out on a few more transforms in the meantime.

[rreusser]

I don't know why this comma exists in the output, but perhaps it's nothing problematic. A large library with lots of glsl like plotly.js compiles fine, so I'm led to believe there's not a fundamental problem here. I'm going to check it off since I'm not concerned enough to investigate too deeply, but if it looks fishy to someone else, I'm glad to dig a bit.

[rreusser]

From the browserify docs on opts:

Options sent to the browserify constructor are also provided under opts._flags. These browserify options are sometimes required if your transform needs to do something different when browserify is run in debug mode, for example.

As mentioned above, my feeling is that there are two approaches to this:

1. Require the user to provide dummy opts that make the transform behave correctly. I don't like this option because unless it's documented very prominently, it's pretty hard to catch, and also puts the burden on the user to obey a random quirk.
2. This PR fills in dummy opts. The only downside here is that it could potentially cause a breaking change with some unknown transform, though it seems unlikely. More likely is that the breaking change is for it to now work, as for glslify. This might justify a minor version bump.

Oh, the only other issue was the type of opts._flags. From what I can tell, it's just a field and the value could be anything that's useful. glslify applies no constraints. One of the browserify tests just sets it Infinity. I think we could make it true. But an empty array seems okay with me.

[rreusser]

@bpostlethwaite Yes, I cleaned up a couple small things. I'm content.