.tmp dir feels confusing

[x1ddos]

I spent a good chunk of time to understand where my generated files were and finally realized there's a .tmp dir.

I find it quite confusing. Wouldn't it be better to just generate stuff where it belongs to, in app/ dir?

[arthurvr]

Wouldn't it be better to just generate stuff where it belongs to, in app/ dir?

That's exactly the point of the .tmp directory, not to clutter the actual source files (in app/). .tmp is where it deserves IMHO. We could document it better, though there shouldn't be a reason to see the compiled files.

[x1ddos]

That's exactly the point I'm arguing against: I don't find it cluttering.
Just wondering, what opinions of others are.

[x1ddos]

Or rather, I find that .tmp introduces more problems than it's trying to solve.

[arthurvr]

I think there should be a clear distinction between the actual source code (app/) and the compiled code, it might end up confusing if there isn't. Definitely given that many people might be using PSK without knowing much about how a build pipeline and preprocessing works.

That said, if there's isn't a clear distinction, it's also going to end up difficult to develop the actual build pipeline. How can you know if a user meant something as a source file or if it's a file put there as temporary?

And how can you easily keep all non-source files out of your version control system?

[robbbz]

I'm with @arthurvr on this one. 👎

For starters, having no clear distinction between the two may not be a problem for development of the actual build system, but keep in mind that many people who know less about things like this also need to be able to extend the build system after downloading PSK. I bet oftentimes there are tiny (or bigger) things that people want to change.

Secondly this is consistent with what WSK and pretty much any build system out there (all yeoman generators for example) do. That makes it way less confusing as people are used to it.

[x1ddos]

So, I've gathered two points from the comments so far:

• it's easier that way for people who are just getting started
• it is consistent with WSK and yeoman generators.

I'd love to hear some arguments that involve people who's already far along + something more general than yeoman as that is just a means, an implementation detail.

Things that .tmp makes worse in my case:

• harder to have a consistent view of my app, as in "app folder is my app"; I can't even see .tmp dir as it is hidden.
• serving from different directories is not common outside of browsersync world when running local dev server. normally you'd just have one directory as the root of your app.
• harder to integrate with external tools. a lot of them rely on the fact that, again, there's a single app root folder with a known structure. e.g. styles for css, js for javascript, etc.

[arthurvr]

it's easier that way for people who are just getting started

IMHO, not only for people that are just getting started. Those are compiled files and you're simply supposed not to care about them, except if you use the actual build process to publish the app, but then everything will end up in dist/.

harder to have a consistent view of my app, as in "app folder is my app"; I can't even see .tmp dir as it is hidden.

IMHO that doesn't really matter. If the build process is doing alright, you never have to know where those files are and never have to see them. Having non-source files hidden is the desired behaviour in most cases.

serving from different directories is not common outside of browsersync world when running local dev server. normally you'd just have one directory as the root of your app.

harder to integrate with external tools. a lot of them rely on the fact that, again, there's a single app root folder with a known structure. e.g. styles for css, js for javascript, etc.

That would never work anyways, as we define other routes. Then you'd need the bower components in there too.

Also, about serving the app directly using a non-browserify server, you could as well just run gulp to build to app and run the server from there, in the rare cases one would like that.

But anyways, this all boils down to opinions and the way one looks at things so I'm going to stop discussing it. Don't want to waste too much time nitpicking.

[robbbz]

I was about to comment nearly the same, but then @arthurvr did it for me. :p To me, the disadvantages you listed there don't really make sense to me as you not ever want to touch/see those files.

But anyways, this all boils down to opinions and the way one looks at things so I'm going to stop discussing it. Don't want to waste too much time nitpicking.

Indeed. Same here.

[jannakha]

here's a great training video why stuff is where it is:
http://www.pluralsight.com/courses/javascript-build-automation-gulpjs

[x1ddos]

Thanks Janna, but that video seems to be locked down under a subscription.

Anyway, I'd love for someone to address the downsides I mentioned in my
list.
On 28 Jul 2015 7:38 am, "Janna" [email protected] wrote:

here's a great training video why stuff is where it is:
http://www.pluralsight.com/courses/javascript-build-automation-gulpjs

—
Reply to this email directly or view it on GitHub
#280 (comment)
.

[Frikki]

@crhym3 LEt me try to address the downsides mentioned in your list

harder to have a consistent view of my app, as in "app folder is my app"; I can't even see .tmp dir as it is hidden.

You do have a consistent view of your app, which is in your app directory. Whichever temporary files are created during a development build process is irrelevant to your consistent view, because what is in the app directory is your app.

serving from different directories is not common outside of browsersync world when running local dev server. normally you'd just have one directory as the root of your app.

The express server, for example, allows to specify multiple directories to serve static content from by using the express.static middleware.

Whether it is common or not is irrelevant, and it is an appeal-to-tradition fallacy, because there is nothing presented to why the claimed tradition is the correct way. Neither tradition nor novelty is necessarily good, and we cannot base arguments on these grounds.

harder to integrate with external tools. a lot of them rely on the fact that, again, there's a single app root folder with a known structure. e.g. styles for css, js for javascript, etc.

I cannot really address this, because I haven’t had any difficulties worth mentioning integrating external tools in my projects. Could you please tell which difficulties you are facing and which tools you are trying to integrate? If a tool is somehow limited to a specific and rigid directory structure, perhaps the tool is not right for the job.

[robbbz]

Anyway, I'd love for someone to address the downsides I mentioned in my list.

Then I feel like you're totally ignoring @arthurvr's comment.

The express server, for example, allows to specify multiple directories to serve static content from by using the express.static middleware.

Yes, and WSK even takes adventage of that feature. Because bower_components lives in the root, the app won't work with a simple server there anyway.

If a tool is somehow limited to a specific and rigid directory structure, perhaps the tool is not right for the job.

Yeah, if a tool is limited to "this is a directory and that should be your website", then that tool is honestly total crap.

[Frikki]

@robbbz It is a bit confusing when you quote both @crhym3 and me in the same comment without referring to which the quote belongs. Initially, I thought you were suggesting that I was totally ignoring @arthurvr’s comment.

[ghost]

My opinions here don't make too much sense and feel free to ignore them, but I think the points @Frikki listed are really valid (and in fact a reiteration of what @arthuvr said)

harder to have a consistent view of my app, as in "app folder is my app"; I can't even see .tmp dir as it is hidden.

I don't understand why you care about seeing the compiled files. The app folder is your app. The rest is temporary things you never, ever have to change or even see. They're temporary (as clearly pointed out by the directory name) so changing them would at all not make sense.

serving from different directories is not common outside of browsersync world when running local dev server. normally you'd just have one directory as the root of your app.

In most modern (front-end) webapps that's not possible any more. People need simple routing for dependency systems (see blogpost robbbz linked to) and similar things. The times I can just run a simple Python server in a directory to serve something serious are rare.

Yeah, if a tool is limited to "this is a directory and that should be your website", then that tool is honestly total crap.

That's really (too) strong wording, but I believe that's where it comes to and I agree.

It is a bit confusing when you quote both @crhym3 and me in the same comment without referring to which the quote belongs. Initially, I thought you were suggesting that I was totally ignoring @arthurvr’s comment

I agree. I think what robbbz meant is that you're in fact just re-wording what arthurvr already tried to explain.

That said, if there's isn't a clear distinction, it's also going to end up difficult to develop the actual build pipeline. How can you know if a user meant something as a source file or if it's a file put there as temporary?

I think that's really valid concern and you forgot to add that to your list.

Thanks for taking my opinions in consideration or at least taking the time to read.
东 栋

[robbbz]

@robbbz It is a bit confusing when you quote both @crhym3 and me in the same comment without referring to which the quote belongs. Initially, I thought you were suggesting that I was totally ignoring @arthurvr’s comment.

Accept my apologies. It's 4AM here and I just came from a plane. I meant to quote the following part:

Anyway, I'd love for someone to address the downsides I mentioned in my list.

[Frikki]

@robbbz No worries.

[x1ddos]

You keep saying "temporary" or "compiled" files but they are not. Compiled is what ends up in dist in my view. The result of turning a sass file into an uncompressed css is as good as any other source file.

I could also have other [third party] css (not sass) in app/styles, or generate an html file with some external tool. Should that all end up in the .tmp dir as well? That's just feels wrong, to have half of the app source code in .tmp, and the other half in the original directories.

[x1ddos]

Could you please tell which difficulties you are facing and which tools you are trying to integrate?

Starting from as simple as uploading an uncompressed version (note: different from dist contents) to a staging or test server. It is much simpler if you have one root directory and just copy everything to a remote location.

It all works well until it doesn't and you need to debug your pipeline, which ends up wasting time on chasing a file location for e.g. a manual inspection.

What if I end up with a checked in app/index.html and also auto-generated .tmp/index.html? That surely leads to a confusion as to what is actually being served on localhost:3000/index.html. This is a trivial example but you get the idea.

[robbbz]

You keep saying "temporary" or "compiled" files but they are not. Compiled is what ends up in dist in my view.

Yes, for production. But the .tmp is where files get compiled to for development. There's, as @twixie said, "temporary things you never, ever have to change or even see"

I could also have other [third party] css (not sass) in app/styles, or generate an html file with some external tool. Should that all end up in the .tmp dir as well?

Yes. And honestly, I hope you won't take any offense by that, but if you have third-party/generated things in your app you're doing it wrong. That's where package managers (like bower) and build systems are for.

Starting from as simple as uploading an uncompressed version (note: different from dist contents) to a staging or test server. It is much simpler if you have one root directory and just copy everything to a remote location.

I'm going to repeat what I said earlier, that's a bug in the tools you're using. A modern development workflow requires at least some simple server (more than serving a directory, like simpleHTTPServer in Python)

And if I may be honest to you, you seem to miss a basic understanding of build tooling and modern front-end development workflows. You're trying to fix a non-problem, by introducing an idea which was proven to be bad practice even before front-end build system came up. (Rails for example made the same mistake years ago)

[robbbz]

Can I also point out that the way we're doing it is the same as nearly every build system, and the way recommended in the Gulp documentation? For me that's argument enough to think that people are going to be confused when we do it @crhym3's way.

[x1ddos]

I wasn't trying to fix anything, barely expressed my opinion.

At the end this thread seems to boil down to "you're doing to wrong". I think it's good enough for me to just close this issue, then.

[Frikki]

@crhym3 As a final comment, leaving aside the discussion on external tools but focusing on the uncompressed version you’d like to upload, for whatever reason, I think this requirement lies beyond the scope of the PSK. In such a case, I would suggest you add a new gulp task to suit your needs. Basically, doing the same as the default task, but leave out any compression, etc.