Foundation-emails: [Suggestion] Imagemin packages should not be part of the stack

[cossssmin]

Can you please take into consideration removing the image optimization packages from the stack?

These packages should be optional, because they:

• use a bazillion dependencies, which makes every project contain (literally) 100.000 files
• ^ because of that, if you're working in a Dropbox/OneDrive/etc folder across multiple computers, it's a never ending syncing nightmare
• aren't really needed: devs can optimize images themselves, either online or by opting-in to install these packages
• , on Windows at least, are very hard to delete because of the amount of the dependencies that creates paths too long for Windows to handle (node_modules inception); I personally had to create a new letter drive with subst in Command Prompt, to be able to delete them
• should be used in the design phase, not the development phase (former comes first anyway, because width x height are needed in dev, while 200KB vs. 79KB can be tackled at any stage)

Removing them would also make the setup process much faster.

Thoughts?

[rafibomb]

We obviously think it's a valuable add on thought we're open to make this an optional dependancy. Are you familiar with how to do that?

How would using it in the design phase be better? The assumption is that image minification is good for production to lower image file sizes. It shouldn't matter what the physical dimensions of the image are because the file size will be reduced either way.

[cossssmin]

Thanks for replying. Unfortunately no, I'm not familiar with how to do that.

What I meant with the last point in my reasoning, was that first you design your layout, which in turn dictates how you code your email (that's where the physical dimensions come in place).
But, when building your email, you don't do it in production, so image file size doesn't matter at this point: it matters only when you test and launch the email, before which you can easily optimize the images in a separate process (either having imagemin installed separately through npm, or by exporting them optimized from your design tool; with the latter making imagemin return modest file size reduction results).

I realize it is useful comfortable to have it, but given the dependencies nightmare, it think it would be better to have it opt-in.

[davidhouweling]

@rafibomb to make it optional, it would be done via the yeoman generator. I've done it with projects on my side. But I definitely think it should be in by default, but you can make the yeoman generator allow it to be optional.

@hellocosmin I am on Windows as well so I can share my experiences.

1. I would suggest not synchronising your projects via Dropbox/OneDrive... use GitHub. Dropbox/Onedrive isn't intended for application development, so its a bit silly to be using it for that purpose. With GitHub you have the ability to pick and choose what folders sync, so you can stop node_modules from syncing, and ultimately if you're concerned about having your repositories public... it has options to have private repos... just don't be silly and check in code which contains credentials.
2. Given you're on Windows, use npm version 3. By default, node 4.x and 5.x comes with npm version 2, however if you force the upgrade to version 3, npm by default does dependencies as a reasonably flat structure (think NuGet style), making the Windows limitation minimal (it does happen still, but a lot less likely). This will solve that issue about having difficulties deleting the node_modules folder due to path being too long.
3. Most designers do not understand how to save images for the web, they will give you assets from a PSD which is design for print, not web, so having a tool like image-min is important. You may have designers that are aware of this, but many (i've worked across several large companies) do not. Having this part of the build process is an important one. Perhaps if you feel that it shouldn't be done all the time, that is fair enough, it could be relegated to the production build, but I don't see the harm either way.

[cossssmin]

@davidhouweling thanks for the insights :)

1. Yes, I know Dropbox is not meant for dev (btw, it has the same ability to choose what to sync to a PC - which is what I ended up doing).
   Ideally I would use a private Github project, but that's a complicated matter at the company I work for, and was not the point (nor do I want to bring it as an argument here) + long paths would still be an issue.
2. Thanks for the tip! Will give it a run and see how it goes.
3. I know that, but it won't be the designer who will be coding the email and putting the images into the template. It'll be the dev, who knows what to do anyway.

My suggestion was for a simple-as-possible stack, not to overload things and have a swiss army knife. The simpler, the better. And if one desires image optimization modules, they could be made optional, as you noted :)

Thanks again for the input guys, appreciated.

[rafibomb]

Great discussion!
So @davidhouweling 's idea about moving to a Yeoman generator for building projects. In the meantime you can remove the pipe for imagemin

[DanielRuf]

We could move it to òptionalDependencies`but this would produce bigger zipped projects for future users.

I would also not remove this as this is very important for email.
You can use the template, adust the gulpfile and remove unneeded dependencies.