While upgrading WhereDoIVote to use the 0.2.2 version of the theme, I found that using yuglify ^0.1.0 minifies the js incorrectly and breaks all your front end code. Downgrading yuglify to 0.1.4 fixed the issue for me. I haven't tested this with the 0.3 version of the theme (it doesn't have the exact same js dependencies, so the issue may not reproduce), but you may find that next time you deploy WhereDoIVote, you install yuglify here https://github.com/DemocracyClub/who_deploy/blob/6315b9f6252af45a3a02fcebc2716c3daf972499/roles/install_initial/tasks/main.yml#L16-L19 , it grabs 1.0.1 and breaks all your stuff.. so bear that in mind. I think based on the release dates that 0.1.4 would have been current last time you deployed WhoCIVF?
Where we are relying on js tooling like this (regardless of whether it is yuglify or something else), it is probably better to explicitly declare the dependency and version in the theme rather than rely on a global dependency.
The second issue I've hit with yuglify is that it doesn't minify polyline.js correctly. You end up with the polyline object being called n or z or whatever it has decided to rename the variable to. This is fix-able if I was using the underlying uglify-js directly because you can pass
mangle: {
except: ['polyline']
}
as a configuration option, but yuglify hard-codes mangle: true and doesn't expose the option. I think with WhereDoIVote I will look at using a different minifier (rather than forking polyline.js and editing it so it minifies cleanly). We might also want to consider whether we should move the theme to a minifier that is a bit more flexible in the configuration options it exposes (yuglify is quite inflexible and opinionated in this respect) so we can work around issues like this more easily in future.
The point about declaring a dependency version in the theme still stands even if we switch to a different library.
While upgrading WhereDoIVote to use the 0.2.2 version of the theme, I found that using
yuglify ^0.1.0minifies the js incorrectly and breaks all your front end code. Downgrading yuglify to0.1.4fixed the issue for me. I haven't tested this with the 0.3 version of the theme (it doesn't have the exact same js dependencies, so the issue may not reproduce), but you may find that next time you deploy WhereDoIVote, you installyuglifyhere https://github.com/DemocracyClub/who_deploy/blob/6315b9f6252af45a3a02fcebc2716c3daf972499/roles/install_initial/tasks/main.yml#L16-L19 , it grabs1.0.1and breaks all your stuff.. so bear that in mind. I think based on the release dates that0.1.4would have been current last time you deployed WhoCIVF?Where we are relying on js tooling like this (regardless of whether it is
yuglifyor something else), it is probably better to explicitly declare the dependency and version in the theme rather than rely on a global dependency.The second issue I've hit with
yuglifyis that it doesn't minify polyline.js correctly. You end up with thepolylineobject being callednorzor whatever it has decided to rename the variable to. This is fix-able if I was using the underlyinguglify-jsdirectly because you can passas a configuration option, but
yuglifyhard-codesmangle: trueand doesn't expose the option. I think with WhereDoIVote I will look at using a different minifier (rather than forkingpolyline.jsand editing it so it minifies cleanly). We might also want to consider whether we should move the theme to a minifier that is a bit more flexible in the configuration options it exposes (yuglifyis quite inflexible and opinionated in this respect) so we can work around issues like this more easily in future.The point about declaring a dependency version in the theme still stands even if we switch to a different library.