Makes sure your asset_compress file has no duplicates!
This plugin requires Grunt
If you haven't used Grunt before, be sure to check out the Getting Started guide, as it explains how to create a Gruntfile as well as install and use Grunt plugins. Once you're familiar with that process, you may install this plugin with this command:
npm install grunt-asset-compress --save-dev
The "asset_compress" task
In your project's Gruntfile, add a section named
asset_compress to the data object passed into
A string that provides the path to your
asset_compress.ini file relative to the
Gruntfile.js that is executing this task.
An object that provides key-value pairs that resemble combinations of sections in your
asset_compress.ini file. See the examples for more detail.
An object with key-value pairs to replace the key with the value in each checked filepath.
An array of strings of files that are generated automatically during deployment. Use this to suppress errors about non-existent files; turning them into warnings.
In this example, the
src option clearly points to our
asset_compress.ini file, but it could realistically point to any
groups option lists pages with their different themes. At the end of every chain you will have to provide a string to a section's name, or an array to several sections' names.
Whether you're a programmer or not, all contributions are very welcome! You could add features, improve existing features or request new features. Assuming the unit tests cover all worst-case scenarios, you will not be able to report bugs because there will be no bugs.
If you want to make changes to the source, you should fork this repository and create a pull-request to our master branch. Make sure that each individual commit does not break the functionality, and contains new unit tests for the changes you make. Existing assertions will not be edited until a major release to remain compatible with older versions, so please do not change them unless absolutely necessary.
To test your changes locally, run
npm install followed by
As much as we want everyone to always use the latest version, we know that this is a utopia. Therefore, we adhere to a strict versioning system that is widely accepted:
major.minor.patch. This is also known as the SemVer method.