Make it easier to load resources in production

[FREEZX]

In the current state of the project, when you build the application (mincss+uglify), the minified results are placed in the public/dist folder.
If you were using relative paths for images, fonts and such in css files, (which in my opinion is a logical solution, instead of writing /modules/something in front of every resource needed), your app won't load resources due to different paths of minified css and the actual path of resources.
For this type of thing to work, it is much needed for the build script to also copy all other resource files to the dist folder with their original file structure, and also putting the minified css to public/dist/css folder.

This should work out of the box, instead of having to manually change paths in all css files or moving files around manually.

[ilanbiala]

The easier solution would be to create a dist folder in each module and place CSS/JS there, but that is something that can be changed by the user. I don't see an issue with us changing it as long as most people are in favor of the change.

[FREEZX]

in my config i added a base path that should point to the base url of the CDN, and i added a base tag in the main layout file.
Now, because the minified css is inside the dist folder, i changed it's build destination to dist/css, added a grunt task to copy everything from modules/*/img/ into dist/img so the relative paths in the css files can work (../img/pic.png). I made a copy task that copies everything from public/lib/ to dist/lib/, and another one that copies all angular html templates with the original folder structure into dist/.
By doing things this way i'm sure that the dist folder contains everything that should be put on CDN and everything should load correctly, although the solution is not perfect.

[ilanbiala]

@codydaig @mleanos any thoughts on this? Not much in our implementation has changed, but loading resources is always something we should try to improve imo. I also want to see if you guys have any thoughts on whether this is really holding anything back or we should just close and come back to it when we do a much larger refactor.

[codydaig]

@ilanbiala I honestly hadn't though much about this because I don't actually MEAN in production. However, I do think this may be a little bigger of a priority if it causes issues in the production environment. @mleanos thoughts? You've had experience in production.

[lirantal]

This topic is definitely an important issue to handle.
Would anyone like to review how we can approach a similar production build (dist directory) for this?

cc @codydaig @mleanos @ilanbiala @FREEZX

[FREEZX]

On the project i had worked on, what i said i did in my last comment is still in place and works well enough.

[lirantal]

@FREEZX is it open source? can you show us an example of such implementation?
are you able to offer a PR?

[lirantal]

@FREEZX also see my suggestion for the dist/ directory here: #1087 (comment)

[FREEZX]

@lirantal No, it's not open source unfortunately.
I also have this on my own framework which might prove useful:
https://github.com/FREEZX/nuke.js/blob/master/build.js
What it does is it goes through all the CSS files, finds all resources they use and copies them together with the minified css files.

[lirantal]

Ok, saw it.
I think there's probably a better and more intuitive way of doing it with existing tools in gulp so if we don't have a PR for this I'll close it.