I'm working in a new skeleton for docpad using zurb's foundation 4.
you can check it out the progress here: https://github.com/dospuntocero/zurb-foundation.docpad
but every time i do a small change on the files it takes 8-12 seconds to regenerate files and it regenerate 47 files... no idea which ones (im just modifying one)
info: Generating...
info: Generated 47 files in 11.013 seconds
info: Regenerated at 22:15:08
info: Regenerating at 22:16:59
info: Generating...
info: Generated 47 files in 9.551 seconds
info: Regenerated at 22:17:09
info: Regenerating at 22:22:48
so it's kind of super slow, almost unusable. i'm using foundation 4 as a git submodule.
If you modify a file, DocPad will also regenerate all files that reference other files, that being documents that do something like #getCollection, #include, #getDatabase, whatnot. It also includes stylsheets, as if I modify a stylesheet, I would expect that the stylesheets that import that stylesheet are also regenerated.
We can make this more intelligent, by keeping track of exactly which files documents reference. There is a discussion here about how we could accomplish such a thing - https://github.com/bevry/docpad/issues/336 - but it is a difficult task.
For the meantime, you can add standalone: true to your document's meta data - more info here. That will tell DocPad to only regenerate that one file, rather than all files that could possibly reference it. I use that a lot during development especially if I am modifying a particular file like crazy, then I remove them once development has settled down to ensure that file is always generated properly.
Related
My minified bundle size is 246kb. I am seeing if I can getting smaller and I read that extracting vue and jquery using mix.extract(['vue', 'jquery']); can help do this. I added this to webpack.mix.js` and now it created 2 files rather than 1. It made: 1) app.js which is 161kb and 2) vendor.js which is 180kb. What is the benefit of this if both need to be included in the page anyways?
This is mainly abut caching unchanged files. For example: while you developing app you are changing the files, adding your own code to your project and then recompile them all together. But vendors are the core libraries which you are never edit their code again. So there is no need to compile them again and download all source code in app.js file. Thus when you extract vendors which they are unchanged files then your cached content size will increase and it also decrease download time of your application because of less changed files must be downloaded again.
It helps you to optimize the file size of the files that client needed to download. Thus speed up the page loading speed even you have updated your site.
Check the documentation.
One potential downside to bundling all application-specific JavaScript with your vendor libraries is that it makes long-term caching more difficult. For example, a single update to your application code will force the browser to re-download all of your vendor libraries even if they haven't changed.
I am using webpack to bundle my files into two file: app.js and lib.js and I create and append unique chunkhash for each of my files that get download by browser. Both these files are built together in the same build output. It would look like this:
lib.747c2ee515b25d871bd0.js
app.e6a0b36a5bb2bff41393.js
I have following caching set on these files:
Cache-Control:private, max-age=31536000
This means that these files will be cached for an year or when a new file arrives. And this would work independently for each file.
Since our application is closer to release, there more changes in app than in lib.
Problem: The problem I am facing is that in a new build, contents of the lib are not changed but module ids are changed. This is causing module ids to change but chunkhash doesn't change; causing downloading of app but not lib resulting into broken app. On Ctrl+F5 everything starts working again as expected.
Questions: Isn't the changed module ids considered as part of chunkash? How do I fix this problem? Is it possible to add auto-increment explicit version number to file names through WebPack?
Any help will be much appreciated.
If you're using webpack-md5-hash plugin to change the webpack chunkhash then you might be hitting this issue.
Also these two articles might help Predictable long term caching and Long term caching of static assets with webpack.
The way I solved this is by adding one more number (which is Date.now()) into my file names as below.
filename: `[name].${Date.now().valueOf()}.[chunkhash].js`
This works pretty reliably for foreseeable time. This is with an understanding that the value returned by Date.now().valueOf() is the number of millisecond since midnight January 1, 1970 UTC. Besides, all I want to achieve here is the value be automatically generated and different from previous one.
The only drawback I see with this method is that: With each release, this forces all the bundles to be refreshed. However, this is not a so much of a concern considering very low frequency of production rollouts we will have after first 2 releases.
I have this
but I would like to eliminate uring the IF statement whenever I want to load such resources.
in the above figure for LOCAL environment I have bootstrap.min.cs and app.css files so that I can debug easily.
in PRODUCTION these two files are minified and combined in one file at core.min.css (using gulp).
is there a better way without using an IF statement but still be able to debug easily using the original files on LOCAL environment?
something like app-local.css (which includes two raw files) and app-production.css (which is one file minified and combined)?
not sure if I'm clear but I hope you get what I mean.
Webpack and Gulp combination is exactly what you are looking for.
It doesnt matter if you are in production or in local you can merge all your CSS and Javascript files as minified into single file. So you don't have to worry about your environment. Also you can use them to watch your changes in real time which is handy for development too.
check this link for more information https://webpack.github.io/
In generator-angular, grunt-usemin is configured to revision static assets using grunt-filerev.
Grunt-filerev's sole responsibility (I looked through the code) is to rename the files. It then returns a summary object of the files renamed.
During the build process, grunt-usemin will then rename references to the static files in your projects folders (in my project, I can see it happening with imgs in html templates).
Fonts, however, get the revision hashes rename, but their references in my Sass files are not updated to reflect that - therefore, I get 404s on all my custom fonts.
I have already reached out time and again on issues in GitHub, but it looks like the good folks over there are respectfully busy with other business.
The question is: is this a configuration error on my part which is easy to adjust, or a bug in grunt-usemin.
Somehow, my blocks, foundation, and common folders got deleted. I still have my Sass cache files - is there any way I can get the original SCSS files out of them?
Currently, I am able to go through the scss-cache and grab a few styles - hope is not lost. But there's a bunch of compiled crud throughout the SCSSC file.
In the meantime, I'll be setting up a version control system for the office.
Sass caches parsed documents so that they can be reused without parsing them again unless they have changed.There is no way they can be used to get the original SCSS files