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

[NPM Scripts] Image minification granularity of changes #7

Open
ryansalerno opened this issue Mar 27, 2018 · 0 comments
Open

[NPM Scripts] Image minification granularity of changes #7

ryansalerno opened this issue Mar 27, 2018 · 0 comments

Comments

@ryansalerno
Copy link

Currently, all images get recompressed whenever any single image changes.

Ideally, we could only compress any new files, but we also need to be mindful of deleting any files in lib that are deleted in src. Clearing out the lib folder takes care of this easily, but not intelligently.

onchange is watching the filesystem and does actually emit events. Sort of. It's built on top of chokidar and passes its events along, which gives us add, change, and unlink.

NPM scripts don't make parameters easy, but you can get there. So, if the change is add we can compress just one file. If the change is unlink we can rm that same file. But if the change is change we'll know the original file that changed, but not what it changed to and therefore we can't grab just that changed file for compression.

Okay, but add/unlink are already wins, so even if we clear the folder and recompress everything on the change event, that's still more efficient and somewhat smarter:

"imagemin:one": "imagemin $1 -o $npm_package_config_libpath/assets/${1##*/}",

"_build:images:add": "npm run imagemin:one",
"_build:images:change": "scoped(){ npm run build:images; }; scoped",
"_build:images:unlink": "scoped(){ rm -f $npm_package_config_libpath/assets/${1##*/}; }; scoped",

"watch:images": "onchange \"$npm_package_config_srcpath/assets\" -- run-s _build:images:{{event}} -- {{changed}}",

Unfortunately, this never really worked. I sporadically got zero-byte files in lib and it was just generally more flaky and unreliable than the nuclear option of just running imagemin on the whole directory every time--which is where we started and now where we've ended up. Ugh.

Leaving this open so no one has to throw quite as many hours into getting this far as I did and maybe someone can do this in a way that actually works one day....

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

1 participant