Style Development for unpublished, or private or local styles

[roblabs]

Launch Checklist

• Briefly describe the changes in this PR.

adds support for Local Style Development
As a Maputnik developer, you can serve styles on the same server that used to develop the Maputnik app. This is useful if you want to test a style that is not public, or is in development.

• Write tests for all new functionality.
• Add an entry to CHANGELOG.md under the ## main section.
  updated README with a description on how to test & use this feature

[HarelM]

I don't think this is the right approach to this project.
You can simply open a file from your machine and edit it, can't you?

[roblabs]

This documentation enhancement for Local Style Development also works for private, non-production styles. This PR shows others how to use this idea.

Useful for Private or Local style development

Private Styles

• Use Maputnik on localhost to review a style, or alternatively publish a new copy of Maputnik as your team requires
• Edit src/config/styles.json to the private URL of your style

Local Styles

• Edit src/config/styles.json to the locally served URL of your styles
• Vite configures CORS

Our case

• Our data team and cartographers do not need to download a style and load manually (reduces error in reviewing styles)
• We make use of the non-production styles to review data layers, and cartographic details
• See https://doi-nps.github.io/maputnik, where we separate our four MBTiles data layers into four separate styles for visualization & inspection.

---

[roblabs]

@HarelM — There were four use cases in this PR (private or non-published styles, documentation on how to, and a team's own copy of Maputnik)

I didn't realize it when I first approached this idea, but hopefully some teams will find use of this.

[HarelM]

For running a local server, you can use st, it's a lot simpler.
If you are running a hosted version of maputink, and you want to change how it behaves, you can do it locally on your code and alter what's needed according to your needs.
I don't think a documentation for how to change the code in order to allow more private styles is relevant - you can simply paste a URL, no need for complicated instructions...

Bottom line, I don't see how this helps anyone, sorry, I might be missing on what the problem statement or the relevant use cases...
But if you are running a fork then you are free to do what you want...

[zstadler]

I usually do my style development opening Maputnik from maplibre.org in my browser and opening a file located on my PC. Using this approach there is no need to:

1. Install node and maputnik
2. Run a Maputnik program/server
3. Notify the Maputnik program in advance about the style files I'd like to edit through editing of src/config/styles.json.

and I can run as many instances of Maputnik as I like, each in a separate tab.

I think the word "Upload", mentioned several times in the "Open" pane, is incorrect and misleading. It should be rewritten as "Open" or "Load"

The README.md says that when using Maputnik in the browser no data leaves the local computer:

Design your maps online at https://www.maplibre.org/maputnik/ (all in local storage)

As far as I understand when a style is opened (so-called "Uploaded") from a local file by the browser, it does not get "uploaded" anywhere. The browser's developer console (F12) supports this understanding. Therefore, there is no risk of an Intellectual Property leak. Is my understanding correct, @HarelM?

In my opinion, if a new "Local Style Development" section is added to README.md, it had better describe the simpler use of the Open/Upload approach.
Another section, potentially titled "Adding local styles to the gallery" could also be added to README.md and describe the process involving the edit of src/config/styles.json.

[HarelM]

Yes, there's no data sent anywhere as far as I know. The uploaded style is kept in the local storage of the browser.