Implementing joy as a webpack loader

[pyrossh]

The js space is pretty matured and generally to develop a good application I would rather use existing tools like webpack, fusebox to bundle/minify/optimize my js and then finally deploy. It would be great if joy could be implemented like a webpack-loader where it compiles golang code to js (es5 preferrably) and from there on things like hot-reloading just come into place and we don't need to reinvent the wheel. Other languages like typescript also are plugged into webpack and this makes it easy for a multi language setup if needed. Is this anyway possible to implement?

[matthewmueller]

Definitely possible and something I'd like to see happen! Since Joy is a binary, you'd use something like

const cp = require('child_process')
cp.exec("./joy")
...

inside your webpack loader

[erbesharat]

I can start looking at webpack documents and work on it if no one is currently working on it.

[pyrossh]

Sure You can. I'm planning on trying to create a fusebox plugin when I get time since I've worked on it before.

[mishak87]

Could implementation of loaders solve usage in vue components via <script type="go">? That would be awesome!

EDIT: It should be possible in components in webpack by using scripts lang attribute <script lang="joy"> and implementing webpack loader. Source https://alexjoverm.github.io/2017/06/28/Integrate-TypeScript-in-your-Vue-project/#4-Use-TypeScript-in-files

[matthewmueller]

I can't wait for this day :-)

[erbesharat]

@matthewmueller I checked webpack's doc, saw that loader API returns content of the given file as a string and I think Joy only accepts a file as an argument. Do you know any solution to this situation?

[matthewmueller]

@erbesharat If I recall, you can get the underlying file path using this inside a loader.

I think Joy needs to be aware of the file path so it can resolve certain imports (though Go's absolute paths should make this not matter). I did just make a bunch of fixes to imports so maybe this is no longer the case. It would need to be tested.

Otherwise, if we can get away with just passing in source, I'd like to add joy < main.go > main.js, which would solve your case.

[erbesharat]

I'm working on the loader, but because of the error I described in #53 I can't go any further.

[tryy3]

@erbesharat If you are refering to the

error flushing error=missing stream name

Error, then you can ignore it, everything works fine, the error comes from Matthew's firehose package, a bit annoying error and should probably be a warning rather then an error. But you should still be able to run things just fine.

[erbesharat]

I created loader's structure, I would be glad if you guys could write a list of necessary features in an issue, check if there are any mistakes or even submit a PR. Right now it's pretty simple, it only runs joy <file.go> and returns javascript code. https://github.com/erbesharat/joy-loader

[tryy3]

@erbesharat Looks good right now I don't think there is a lot of features you can add to a webpack loader for joy since all it can do is compile.

Maybe in the future we can add some options or flags in the command line, I know Matthew was thinking about targetting specific things like netlify with the jolly project so in the future there might be more features.

I have one question though, does webpack write to the file between every loader? Right now you are using this.resourcePath but if you have some loader before joy-loader that modifies that file, will those changes be noticeable to the joy-loader?