Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set up dist folders and serve static assets from there #839

Closed
hallvors opened this issue Nov 30, 2015 · 16 comments
Closed

Set up dist folders and serve static assets from there #839

hallvors opened this issue Nov 30, 2015 · 16 comments

Comments

@hallvors
Copy link
Contributor

The build process job for optimizing jpg and png images overwrites the originals. It's odd to run the optimizations again and again on those same files, and it's annoying that Git actually thinks some of them have changes that should be checked in.

@miketaylr
Copy link
Member

It's odd to run the optimizations again and again on those same files

Yeah, there should be a better way to do this (I hope).

it's annoying that Git actually thinks some of them have changes that should be checked in

That's news to me. I assume this is on Windows for you? Could it be that the Windows and Mac optimizations are not binary-equivalent?

@miketaylr
Copy link
Member

Any ideas on how we could improve this, @magsout?

One idea is we could just make this grunt task a non-default task (that is run when building for a deploy).

@hallvors
Copy link
Contributor Author

Why not send all output from the build process into ./dist or ./built_site or some such?

Would it be hard to only optimize images that are newer than already optimized file inside ./dist ?

@hallvors
Copy link
Contributor Author

Could it be that the Windows and Mac optimizations are not binary-equivalent?

Most likely. I guess if I did check them in you'd end up seeing this issue on your side. git ping pong? :)

@miketaylr
Copy link
Member

Would it be hard to only optimize images that are newer than already optimized file inside ./dist ?

Hm, probably not. We could have the task move them to webcompat/static/img/dist/ (which should be .gitignore'd) and check the last-modified date on those before running the task.

One minor wrinkle is this would allow us to check in large unoptimized files into the repo. I don't know if that will be an real issue in practice though.

@hallvors
Copy link
Contributor Author

hallvors commented Dec 9, 2015

/me thinks that's a feature :-p

Another thing: I'm quite often using "Search in files" to get an overview of the code, and the way our build process keeps built files and source files pretty close in the tree is annoying. It's hard - especially while being newbie - to tell which files are the output of a build process and which aren't. Making sure all output goes to ./dist would be a great improvement.

@miketaylr miketaylr self-assigned this Dec 10, 2015
@miketaylr
Copy link
Member

I'm gonna take this and do the following:

  • make a /dist folder and make all processed files go there
  • update templates to look there

And then I'll see if my "check the last-modified date on those before running the task" plan is annoying to implement or not.

@miketaylr miketaylr changed the title images are optimized againandagainandagainandagain Set up dist folders and serve static assets from there Dec 10, 2015
@miketaylr
Copy link
Member

The build process job for optimizing jpg and png images overwrites the originals. It's odd to run the optimizations again and again on those same files,

I just checked, and imagemin doesn't actually overwrite them or optimize them if there's no gains to be made. But it still spends time attempting to optimize them.

@hallvors
Copy link
Contributor Author

imagemin takes a while to run on Windows and outputs a message saying "n images optimized, 0 bytes saved". Afterwards Git thinks those files were modified. So it's weird :-p

@miketaylr
Copy link
Member

The joys of cross-OS tooling. 🔨

@miketaylr
Copy link
Member

So, thinking more about this it's gonna be a number of hours to make a fix that saves about a minute per build. I guess that adds up, but I propose the following simpler approach: make imagemin non-default but always included for deploys.

We can re-visit a /dist folder later, but there's a lot more important things to get done right now. I'll leave this open if someone wants to work on this -- perhaps a good chance to get familiar with the codebase.

@magsout
Copy link
Member

magsout commented Dec 29, 2015

To avoid these issues, I always avoid touching the original file. I have a build directory with css, js, img, svg etc .. This directory is of course not track by git.

@magsout
Copy link
Member

magsout commented Dec 29, 2015

Maybe we can thinking about migrate to webpack (a good solid webstack) with lot of loader (svg, img, js, css) ..

@miketaylr
Copy link
Member

I agree with @magsout, but it might be a while before we get to webpack. If someone wants to tackle this as an opportunity to mess with grunt and some templates, I think the plan from #839 (comment) would still work.

You would need to create a /dist folder in /webcompat/static/ and make sure all the grunt tasks put built assets there: https://github.com/webcompat/webcompat.com/tree/master/grunt-tasks (pretty much anything that has a destination or output).

We probably want to add dist to gitignore too.

@zoepage
Copy link
Member

zoepage commented Apr 3, 2017

Related to #1352

@miketaylr
Copy link
Member

I think we don't want to do this anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants