Missing static files

[3nprob]

Getting the following errors in browser console after running make Sucre.up.

GET /static/sprite@2x.json 404 (Not Found)
GET /static/sprite@2x.png 404 (Not Found)
Error: Source layer "park" does not exist on source "openmaptiles" as specified by style layer "park".
Error: Source layer "park" does not exist on source "openmaptiles" as specified by style layer "park_outline".

[ellenhp]

Let me see if I can repro. I got CORS issue with those files if I had the public url set as 127.0.0.1 and accessed via localhost, but I haven't seen a 404 recently.

[ellenhp]

Ah, it's because the volume mount was removed from the nginx image. I know it's a bummer to have all those volume mounts in there, so I'm wondering if it makes more sense to actually just bundle the static files into the image? They're static, and fairly small.

[3nprob]

looks like they're static as in common regardless of map/place? Yeah, including such files in the image directly seems reasonable to me.

[3nprob]

How about moving everything currently in tileserver/assets into the nginx image?
I can take a look at that. Only thing I'm not super clear on is if/how https://github.com/ellenhp/headway/blob/main/tileserver/style/style.json.template is actually used right now or if it's just copied into the data directory and not actually used yet.

[ellenhp]

The tileserver-gl-light image serves it out of the data directory. It's so confusing. I want to move not only sprites but also fonts into the nginx image, possibly using a second builder image. If we could serve the style separately from the tileserver that might also be nice. Theoretically the tileserver provides actual value because it has its own interface on 8000 (which I exposed, didn't I.... didn't mean to let that get through, but I added so many SVGs that the self-review was overwhelming)

Anyway, theoretically the tileserver provides actual value, but I'm very frustrated with its config options so I think that moving everything except the tiles out of the tileserver sounds good to me.

[ellenhp]

I was working on this but I have obligations this evening so it'll have to wait til tomorrow.

A few things I ran into: OSM Liberty (which I ended up picking over OSM bright) prefers Roboto Regular, Roboto Medium and Robot Condensed Italic, compared to Noto Sans which is what OSM bright uses. So we'll need to swap out the TTFs and then update the licensing information in COPYRIGHT_NOTICE.md. tileserver-gl-light actually was doing a best-effort subtitution but if we're serving these as static files the name needs to match exactly.

[3nprob]

Got it. What I'm currently looking at is moving both of these into the frontend, so the resulting files would be generated by yarn build and and output into the dist folder.

Any insight into what's happening/supposed to happen with style.json.template? :)

[ellenhp]

Unless I made an egregious mistake, style.json.template should undergo environment variable substitution during the tileserver image startup process and then end up at a path where the tileserver can serve it to clients via a /styles/... path.

…

On June 1, 2022 6:04:45 PM PDT, 3nprob ***@***.***> wrote: Got it. What I'm currently looking at is moving both of these into the frontend, so the resulting files would be generated by `yarn build` and and output into the `dist` folder. Any insight into what's happening/supposed to happen with `style.json.template`? :) -- Reply to this email directly or view it on GitHub: https://github.com/ellenhp/headway/issues/43#issuecomment-1144310089 You are receiving this because you commented. Message ID: ***@***.***>

[ellenhp]

You should be able to adjust the build process to do the same thing during nginx startup? Or potentially even put a style into the frontend if you can make it all relative to the public url. Most mapbox styles hardcode a domain for like the tile sources and stuff but it might work with a url relative to the current domain maybe. If it gets too complicated though I can look at it tomorrow. The way mapbox styles work is really confusing.

…

On June 1, 2022 6:04:45 PM PDT, 3nprob ***@***.***> wrote: Got it. What I'm currently looking at is moving both of these into the frontend, so the resulting files would be generated by `yarn build` and and output into the `dist` folder. Any insight into what's happening/supposed to happen with `style.json.template`? :) -- Reply to this email directly or view it on GitHub: https://github.com/ellenhp/headway/issues/43#issuecomment-1144310089 You are receiving this because you commented. Message ID: ***@***.***>

[ellenhp]

I just realized that I think I want to veto putting the fontnik dependency into the frontend because I want to be able to do frontend development on my laptop which has an arm64 architecture. Fontnik fails to build its dependencies during the npm install on my laptop. The backend already doesn't work on my laptop because of some valhalla issues but the frontend should remain working if possible.

…

On June 1, 2022 6:04:45 PM PDT, 3nprob ***@***.***> wrote: Got it. What I'm currently looking at is moving both of these into the frontend, so the resulting files would be generated by `yarn build` and and output into the `dist` folder. Any insight into what's happening/supposed to happen with `style.json.template`? :) -- Reply to this email directly or view it on GitHub: https://github.com/ellenhp/headway/issues/43#issuecomment-1144310089 You are receiving this because you commented. Message ID: ***@***.***>

[3nprob]

I just realized that I think I want to veto putting the fontnik dependency into the frontend because I want to be able to do frontend development on my laptop which has an arm64 architecture. Fontnik fails to build its dependencies during the npm install on my laptop. The backend already doesn't work on my laptop because of some valhalla issues but the frontend should remain working if possible.

I haven't tried on arm64 yet but this resolved the build errors I had on linux/amd64 at least: mapbox/node-fontnik#178

[ellenhp]

It looks like it might not be maintained at all. :/ Short-term do you want to stick with a docker container? Installation of the package seems to succeed as long as it's on a platform that has binaries in the mapbox S3 bucket, so as long as we control node version, platform and architecture we should be fine.

Longer term, either they accept the patch and we can point to the NPM package in the frontend or worst case scenario I'll probably set up an organization account for this project and we can fork fontnik under that organization account. I'd prefer to avoid taking on that maintenance burden but better to have the software build than to rely entirely on the binaries forever, IMO.

[3nprob]

Yeah, there're several deps there that don't seem to be touched since node 10~12, with quite a few deprecations popping up...

Let's see if the dependency-forking rabbit hole I'm down right now leads anywhere 😅

[ellenhp]

Godspeed! Drop an update here if you do/don't get somewhere. Short-term it would be nice to fix this specific issue the easy way, maybe just with a volume mount. I'll probably do that tomorrow morning if you don't have a PR up by then. But it would be really nice to have all of the tools build from source. I'm uneasy with the fact that we can't really build styles at all without using binaries sitting in a mapbox S3 bucket.

[3nprob]

Still WIP but moving the generation scripts into dev-dependencies of frontend and making it part of the frontend bundling here: #45