Should vendor directory be in src/vendor/ or src/static/vendor/

[anselmbradford]

For any new projects, should the vendor directory be in src/vendor/ or src/static/vendor/? This repo puts it in src/vendor/, while projects like OAH put it in src/static/vendor. Which project is ohh so wrong wrong wrong on this directory placement? OAH or generator-cf? (Checking which flapjack should conform with.)

[contolini]

I lean toward src/vendor/. A project could have an external dependency that doesn't belong in the static/ directory. Like if Bower was used to pull down something for Grunt. It's not a common or reasonable scenario but if vendor/ doesn't need to be in static/ then I vote for leaving it in src/.

[kave]

i would even lean towards having vendor sit on the root project level as /vendor/.
For the mere fact that these are external dependencies which must be downloaded at runtime, and then copied to their respective location.
So that src folder by definition truly only contains code written by contributors.

[ascott1]

I also have a personal pet peeve opinion inspired by @cndreisbach, where we shouldn't use the directory name static for static sites (which, presumably, some of the things created with the generator could be).

[jimmynotjim]

I agree with @kave, but why rename it at all? It seems everything installed in /vendor is coming from bower, why not leave it as bower_components and import/require as necessary?

[jimmynotjim]

This project is no longer installing vendor files, but @ascott1's comment is still valid. I've never liked the static name in a source directory. Nothing that lives in there is actually static, it's always being edited and then being built out somewhere else, so it is in fact, dynamic. Is this worth discussing further in a new issue?

[Scotchester]

Due to the rise in understanding and popularity of the concept of "static" stites, I agree that the name is somewhat confusing now as a home for front-end assets. I still think it's valuable to group such assets (versus having individual css, js, font, and img directories at the project root or src root). I suppose I would prefer the name assets for that grouping folder.

[jimmynotjim]

I'm not sure I agree about not using src root. In nearly every static site there's nothing else in src besides the assets. That said, if we're looking for clarity, what about unprocessed like cfgov-refresh uses? assets could be either processed or unprocessed but unprocessed can only be one thing.

[Scotchester]

I didn't mean to comment on the src folder. A project may or may not have a src folder, depending on its needs. I merely propose static ➡️ assets, regardless of where static currently lives.

I don't like unprocessed because a project may have files in there that don't get any processing (straight CSS, images that are already compressed before being committed, fonts, etc.).

[jimmynotjim]

Those files might not be edited, like say the svg icons, but they are still moved as part of the build process and are therefore "unprocessed" where they live in src.

The reason I disagree about a straight move from static to anything is that most of these projects are src/static/foo where there is nothing else in src and static/assets/unprocessed is an unnecessary directory level.

[Scotchester]

I think you're still partially misunderstanding me :)

Whether or not a src directory is warranted is a wholly separate question from renaming static, which is the only thing Adam was talking about. If it's true that "most of these projects are src/static/foo where there is nothing else in src", then I agree, one of those directory levels is superfluous. I would go just assets/foo (or src/foo if you want to be extra clear that they're source files that get some processing done to them). unprocessed still kinda rubs me the wrong way, I think mainly because you're not going to have processed as the destination, that'd be weird to see in a front-end asset URL.

Here are some simplified examples of the structures I'm envisioning:

Static site kind of thing

assets/
  images/
  scripts/
  styles/
content-subsection-1/
content-subsection-2/
scripts/
  gulp/
  npm/
index.html
Gulpfile.js
package.json
etc.

Personally, I would leave all assets, processed and unprocessed, in the same assets folders (e.g., main.less and main.min.css are in the same assets/styles/ folder, but I can see the potential case for having a separate src folder and then an assets folder (or perhaps even css, js, and img folders at the root – I think it gets to the question of how you want your final asset URLs to be structured).

Something where src/dist would be appropriate

In this model, it should be obvious (if one is familiar with the src/dist convention) what is unprocessed and what has been processed.

dist/
  assets/
    images/
    scripts/
    styles/
  content-subsection-1/
  content-subsection-2/
  index.html
scripts/
  gulp/
  npm/
src/
  assets/
    images/
    scripts/
    styles/
  content-subsection-1/
  content-subsection-2/
  index.html
Gulpfile.js
package.json
etc.

[jimmynotjim]

In your "Static site kind of thing", where do built JS and CSS files go?

[Scotchester]

In your "Static site kind of thing", where do built JS and CSS files go?

Personally, I would leave all assets, processed and unprocessed, in the same assets folders (e.g., main.less and main.min.css are in the same assets/styles/ folder, but I can see the potential case for having a separate src folder and then an assets folder (or perhaps even css, js, and img folders at the root – I think it gets to the question of how you want your final asset URLs to be structured).