Open anselmbradford opened 9 years ago
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/
.
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.
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).
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?
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?
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.
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.
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
:arrow_right: 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.).
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.
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:
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).
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.
In your "Static site kind of thing", where do built JS and CSS files go?
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).
For any new projects, should the vendor directory be in
src/vendor/
orsrc/static/vendor/
? This repo puts it insrc/vendor/
, while projects like OAH put it insrc/static/vendor
. Which project is ohh so wrong wrong wrong on this directory placement? OAH or generator-cf? (Checking which flapjack should conform with.)