Fix build query not including setclasses when passed as an option#1772
Conversation
Includes a correction to the output property in the build query, as the current site expects.
Fix build query not including setclasses when passed as an option
|
Amazing, thanks! |
|
@patrickkettner will this kick off a new deploy for the site or do I need to trigger it? |
|
already set it off On Thu, Nov 26, 2015 at 6:41 PM, Ryan Seddon notifications@github.com
patrick |
|
@patrickkettner I checked the site to see the change in action, however it is still exhibiting the original issue. Was this deployed? Running https://github.com/Modernizr/modernizr-neue locally works fine. |
|
try now? On Wed, Dec 2, 2015 at 6:23 AM, Mike Robinson notifications@github.com
patrick |
|
All good now, thanks! :) |
I stumbled upon this when moving from a manually built Modernizr file to a bower installed one. The build URL provided in the file did not include the
setclassesproperty, so installing through bower as a tar.gz omitted this feature - despite the fact the original file used it.This bug can be demonstrated on the current https://modernizr.com/download site itself:
setclassesExample following these steps using
inlinesvggenerates this codepen: https://codepen.io/anon/pen/KdLxWbThis is happening as the generate script is directly modifying config to remove the setClasses special case option, which means it no longer exists for the rest of the build process (e.g. build-query) to work with.
Another part of this is even if the property was being set, it is using the wrong label anyway, so would still fail to include the
setClassesoption. This PR fixes that too.Its usefulness doesn't just lie with copying the build URL for bower, it also makes it more consistently clear what features were intended to be included. Currently, the "bad" URLs work on the site as "Add CSS classes" is checked by default and replaced into the browser history state - shouldn't really depend on that behaviour.