Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Missing static files #43

Closed
3nprob opened this issue Jun 1, 2022 · 17 comments
Closed

Missing static files #43

3nprob opened this issue Jun 1, 2022 · 17 comments
Labels
bug Something isn't working

Comments

@3nprob
Copy link
Contributor

3nprob commented Jun 1, 2022 •
edited
Loading

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

maps_000

GET /static/[email protected] 404 (Not Found)
GET /static/[email protected] 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
Copy link
Member

ellenhp commented Jun 1, 2022

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
Copy link
Member

ellenhp commented Jun 1, 2022 •
edited
Loading

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
Copy link
Contributor Author

3nprob commented Jun 2, 2022

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
Copy link
Contributor Author

3nprob commented Jun 2, 2022 •
edited
Loading

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
Copy link
Member

ellenhp commented Jun 2, 2022

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
Copy link
Member

ellenhp commented Jun 2, 2022

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
Copy link
Contributor Author

3nprob commented Jun 2, 2022

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
Copy link
Member

ellenhp commented Jun 2, 2022 via email

@ellenhp
Copy link
Member

ellenhp commented Jun 2, 2022 via email

@ellenhp
Copy link
Member

ellenhp commented Jun 2, 2022 via email

@3nprob
Copy link
Contributor Author

3nprob commented Jun 2, 2022 •
edited
Loading

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
Copy link
Member

ellenhp commented Jun 2, 2022

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
Copy link
Contributor Author

3nprob commented Jun 2, 2022

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
Copy link
Member

ellenhp commented Jun 2, 2022

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
Copy link
Contributor Author

3nprob commented Jun 2, 2022

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

@3nprob 3nprob mentioned this issue Jun 2, 2022
Draft
4 tasks
@ellenhp ellenhp added the bug Something isn't working label Jun 2, 2022
@ellenhp
Copy link
Member

ellenhp commented Aug 15, 2022

@3nprob I think this can be closed since I fixed the missing static files issue originally reported, but if you want to revive #45 at some point that would be cool too! It seemed like some good work was happening there.

@ellenhp ellenhp closed this as completed Aug 15, 2022
@ellenhp
Copy link
Member

ellenhp commented Oct 11, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ellenhp @3nprob