Style Guide - Assets folder needed

[hansl]

There were some points brought offline against public/, so the name should be assets/ to avoid confusion and collision.

A project might be comprised of multiple apps; mobile/, e2e/, demo/, client/, ... Library developers might have more, depending on their need. More typically, a project will have a single app in src/.

Each apps could have its own assets/ folder, and a global one could be used and shared amongst different apps.

[johnpapa]

There are a few points we discussed. Maybe we should start by deciding if we want to have one issue to discuss them all or split this out. The main points were:

1. What do we call the folder where we put things that are not code? (e.g. public/ or assets/) These include fonts and images
2. At what level do we put this? Thus implying should we share these non-code assets across multiple apps in the same repo? Or would that be an npm package? Or do we care to guide folks one way or the other?

I'll focus first on the first question first. I prefer assets/. The word public has meant this, true. But it also has other meanings to many in the Web. Public sometimes means the place we put our publicly accessible web root. Sometimes it means assets. The things we are discussing putting in here are not code, but instead assets such as fonts, images, svg, ico. Thus I vote for assets/

For the second issue I I don't think I understand the driving motivation behind having multiple apps in the same repo. 2 use cases come to mind quickly though:

1. A web and mobile app, in the same repo, sharing some similar assets

src/
  assets/
  web/
    app/
  mobile/
    app/  

1. A ui control suite, sharing assets

src/
  assets/
  button/
    assets/
  calendar/
    assets/
  modal/
    assets/

However is it better to add a source code level folder for shared assets or to put these in an npm package? Or do we care at all and make that user choice?

I think I'm fine with multiple in a repo, but I am also fine with splitting these into separate repos for each project. Ive done it both ways and they both have pros and cons. Both ways ultimately work and have no serious flaws, so to me it is "user choice"

Right now with the information I have, I lean towards assets/ as the name of the folder and to just being consistent on your choice for #2.

Comments and feedback welcome :)

[cgmartin]

Point 1 : Naming

I like the naming of assets/ for containing images and fonts, but does the naming still fit for other www root level items, like sitemap.xml, humans.txt, i18n/en.json, etc.? Just throwing this out there: would renaming public/ to something like www_root/ help, or would it be just as confusing? I'm coming from configuring apache/nginx and this seems straightforward to me, but I am likely missing some of the offline discussion.

Would assets/ be a sub folder under www root, or would it _be_ www root? If the former, what would be the method of getting files into www root?

Point 2 : Multiple app dirs

I like the encapsulation of source and assets under an app subfolder. How will the assets folders per app map to www root?

src/
  assets/     -> dist/ ~or~ dist/assets/ ?
  calendar/      
    assets/   -> dist/calendar/assets/ ~or~ dist/assets/calendar/ ~or~ dist/calendar/?

Just keep in mind the mental mapping that will need to occur for URL paths. It would be great if the default pattern is straightforward for devs to understand that if an asset is put "here", they will be able to reference it via simple rules.

Mentioning because this had become a problem with some large projects I've seen with deep levels of sub-apps/modules and inconsistent folder patterns. And to clarify, not saying we shouldn't restrict someone from doing complex dir mappings if they wanted to, just when considering the default output behavior from CLI and general style guide recommendations.

[zoechi]

I'd prefer singular asset/ (for all folders)