Improve .less handling and compiling#8
Open
ggiraldez wants to merge 2 commits intopaulfairless:masterfrom
Open
Improve .less handling and compiling#8ggiraldez wants to merge 2 commits intopaulfairless:masterfrom
ggiraldez wants to merge 2 commits intopaulfairless:masterfrom
Conversation
and ResourceTagLib. Compile the less files from URLs, using resourceService as path resolver.
There was a problem hiding this comment.
I assume this will work better for a problem I'm facing. I had some trouble with deployments having war files that are unexploded.
http://grails.1312388.n4.nabble.com/lesscss-resources-not-working-in-production-tt4429062.html has the discussion for it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hey Paul:
Thanks for your work on this plugin. It's been very useful.
In this pull request I improved the support for .less files from the resources plugin by "monkey-patching" ResourceService and ResourceTagLib. I'm sure this is not the ideal way, but since there's currently no direct support to add asset types in resources, this approach seemed the best option.
This brings the benefit of no longer needing to specify type and rel attributes in the resource declaration. Also, I added operation = "compile" to the mapper so it's now possible to exclude the execution of the engine via the option exclude: 'compile' in the resource declaration. And since the tag lib is patched, it'll render the tag with the appropriate attributes.
The other change is compiling the less files from URLs instead of files. I was using version 0.6 and ran into problems when trying to deploy in a WAR (the mapper was not finding the source file). I think probably your fix in 0.6.1 might have solved the issue, but I didn't know about it until today. Anyway, since the solution I found is different, I'm sending it nevertheless. In any case, I think mine is a more general solution, in part because it uses the resources service to perform the path resolution.
The only complication is that in development mode the mapper wasn't working with resource reloads due to a problem with the class loader (somewhat related to http://jira.grails.org/browse/GRAILS-5592 ). Hence, I added a workaround by setting the context class loader before attempting to compile.
Regards,
Gustavo