foundation-sites: Gulp does not update 'date modified' of dist-directory after changes in partials - (zurb-advanced-template)
I’ve got a rather specific bug and it might actually be a bug from gulp, not foundation. But in any case, it would be great to have a workaround. My Setup:
- Foundation 6.2.0 (advanced template)
- foundation-cli@2.1.0
- OSX
I ran npm install and npm update , too.
How can we reproduce this bug?
- Start
foundation watchin a zurb template, edit any _partial.scss from thesrc/scss/components-directory - Alternatively, edit anything in the default.html in
src/layouts
What did you expect to happen?
- The “date modified” of the
app.cssupdates indist - All html-files update their “date modified” in
dist, since their header and footer were updated by altering the default.html insrc
What happened instead?
- The app.css keeps the date of the original app.scss in
src, regardless in changes in any imported scss-partials. To force an update , it is necessary to make any change in app.scss (like opening it, add a space anywhere, and save). - The “date modified” of individual html-files in
distdo not get updated when you make any changes in the default.html insrc.
I remember that before updating to 6.2 and gulp#4.0, all files in dist got a new “date modified”. I think it’s great that this does not happen anymore, only changed files get updated.
The problem is just that imports like scss-partials or the panini-layout are not registered as changes.
I no expert in gulp, but it seems to be connected to gulp-vinyl. I found these related discussions on gulp: https://github.com/gulpjs/gulp/issues/1414 https://github.com/gulpjs/gulp/issues/1461 It seems it was resolved, though?: https://github.com/gulpjs/vinyl/pull/75 So I guess these bug reports were about the an older bug not updating the date at all, and not about not noticing imported changes.
Edit , here’s the package.json:
{
"name": "foundation-zurb-template",
"version": "1.0.0",
"description": "Official ZURB Template for Foundation for Sites.",
"main": "gulpfile.js",
"scripts": {
"start": "gulp",
"build": "gulp build --production"
},
"author": "ZURB <foundation@zurb.com>",
"license": "MIT",
"devDependencies": {
"babel-core": "^6.3.17",
"babel-plugin-transform-es2015-arrow-functions": "^6.5.2",
"babel-plugin-transform-es2015-block-scoped-functions": "^6.5.0",
"babel-plugin-transform-es2015-block-scoping": "^6.5.0",
"babel-plugin-transform-es2015-classes": "^6.5.2",
"babel-plugin-transform-es2015-destructuring": "^6.5.0",
"babel-plugin-transform-es2015-modules-commonjs": "^6.5.2",
"babel-plugin-transform-es2015-parameters": "^6.5.0",
"babel-plugin-transform-es2015-shorthand-properties": "^6.5.0",
"babel-plugin-transform-es2015-spread": "^6.5.2",
"babel-plugin-transform-es2015-template-literals": "^6.5.2",
"babel-preset-es2015": "^6.3.13",
"browser-sync": "^2.10.0",
"gulp": "gulpjs/gulp#4.0",
"gulp-autoprefixer": "^3.1.0",
"gulp-babel": "^6.1.2",
"gulp-cli": "gulpjs/gulp-cli#4.0",
"gulp-concat": "^2.5.2",
"gulp-cssnano": "^2.1.0",
"gulp-extname": "^0.2.0",
"gulp-if": "^2.0.0",
"gulp-imagemin": "^2.2.1",
"gulp-load-plugins": "^1.1.0",
"gulp-sass": "^2.1.0",
"gulp-sourcemaps": "^1.6.0",
"gulp-uglify": "^1.2.0",
"gulp-uncss": "^1.0.1",
"js-yaml": "^3.4.6",
"panini": "^1.3.0",
"rimraf": "^2.4.3",
"style-sherpa": "^1.0.0",
"yargs": "^3.8.0"
},
"repository": {
"type": "git",
"url": "https://github.com/zurb/foundation-zurb-template.git"
},
"bugs": {
"url": "https://github.com/zurb/foundation-sites/issues",
"email": "foundation@zurb.com"
},
"private": true
}
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 15 (9 by maintainers)
My workaround at the moment is using this additional gulp-plugin: https://www.npmjs.com/package/gulp-touch
npm install --save-dev gulp-touchand then calling it before the browser-reload:Also see https://github.com/ahmadnassri/node-har-validator/issues/112#issuecomment-437378269 and https://github.com/ahmadnassri/node-har-validator/issues/113 why the version was not found anymore.
The author unpublished two versions without a good reason.
Yes, it did! Thanks @DanielRuf 😃
Try
rm package-lock.jsonor manually delete thepackage-lock.jsonfile.