Assets helpers are not CDN friendly

[TankTheFrank]

First

buffalo/render/template_helpers.go

Line 32 in 6a1497f

return filepath.ToSlash(filepath.Join("/assets", filePath))

prepends "/assets" (hardcoded) to the urls from manifest.json making the assets template helpers ( javascriptTag, stylesheetTag, etc) unusable with assets served from a separate domain.

Second, I could not find a straight-forward way of building a binary that packs the "must have" files (templates, migrations, manifest.json) while leaving the bulk of assets from the "asset" directory (css, js, images) unpacked.

[paganotoni]

Hey @TankTheFrank, may buffalo build -e work for you? it generates a separate archive with the assets.

Also, which are your suggestions to make buffalo CDN friendly?

[TankTheFrank]

I forgot to add the fix proposal for the hardcoded path - add "/assets" as "basePath" in webpacker manifest plugin for the default template and remove it as a hardcoded prefix.

[TankTheFrank]

I could be wrong but doesn't -e also adds the packed assets in the binary beside creating the archive? This increases the binary size significantly (esoecially with image assets) and pointless memory at run time when assets are not served from it.

I tried a mix of -k -e and other options and I ended up either without migrations (running migrate did nothing) or with a large file size. The "solution" that seemed to work was to generate the assets, delete CSS, images, js etc from the public dir and build again with -k (skip asset generation). Hence the "no easy way" part.

[paganotoni]

Got it, I don't think its on purpose that -e keeps the assets in the binary as well (after extracting them on the separate archive) so, to me this looks like a bug, (unless @stanislas-m and/or @markbates correct me) would you want to work on a PR for this ? (PR's are always welcome).

Also, thanks for the suggestion on the /assets prefix, let's work on that one as well.

[markbates]

If -e or -k is still packing assets into the binary, that's definitely a bug.

It's mostly an issue with these two lines:

https://github.com/gobuffalo/buffalo/blob/master/buffalo/cmd/build/assets.go#L24
https://github.com/gobuffalo/buffalo/blob/master/buffalo/cmd/build/assets.go#L28

A PR to fix it would be fantastic.

[TankTheFrank]

For the prefix this should do it:

generators/assets/webpack/templates/webpack.config.js.tmpl

 new ManifestPlugin({
+      publicPath: '/assets/',
       fileName: "manifest.json"
     })

render/template_helpers.go b/render/template_helpers.go

-       return filepath.ToSlash(filepath.Join("/assets", filePath))
+       return filepath.ToSlash(filePath)

Basically the "/assets/" prefix is added to manifest.json entries when it's generated instead of being forced at runtime.

[stanislas-m]

I just tested the -e flag and on the development version at least, it works well: the assets are not packaged in the binary.

[paganotoni]

I took a look at it and that's the same I saw.

[H3rby7]

@stanislas-m was there any progress on this issue? Is there anything I could do to fix it?

Apart from the CDN friendlyness this issue also prevents asset helpers being useful if the web-app should not run under the "/" path, but a different path, because it is behind some sort of ingress management.

(see: https://gophers.slack.com/archives/C3MSAFD40/p1572282815126800) - where I also talked to @paganotoni

[stanislas-m]

@H3rby7 The fix proposed in #1030 should work, but we wanted to not break stuff either by providing a fallback, or a fix in the buffalo fix command.

[ArmandBENETEAU]

Hi all,

I am currently trying to extract the assets from the built binary like @TankTheFrank talked about in his first message.

And it seems that I have the same problem: when I pass the "-e" option to the "buffalo build" command line, the assets are correctly zipped in a separate ".zip" file, but they seems to keep being in the binary (basically, the size of the binary doesn't change).

It has to be noticed that I am in "production" mode.

Do I miss something?

Thanks in advance for your help!