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

Add new setting keepFilename that retains the original filename #2

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jonspalmer
Copy link

If keepFilename is true then the original filename is retained with the unique hash appended to it prior to the extension.

In production environment I don't want to completely obfuscate the filenames of the css and js as it makes debugging incredibly difficult. Having the option to retain the original filename allows simple debugging of which files are being loaded etc. while still giving all the benefit of caching resources that don't change in content.

…ust appends the hashed id before the extension.
@andrew-wharton
Copy link

:-) didn't notice this pull request and implemented pretty much the exact same feature.

I think that this means that enough people want this feature to be included that it should be added. It does not matter to me which we use, as long as it gets pulled in.

@tednaleid
Copy link

There's also open JIRA ticket for this with a few more patches :)

http://jira.grails.org/browse/GPCACHEDRESOURCES-3

@divideby0
Copy link

Bump. Are there any plans to merge this?

@jamesdh
Copy link

jamesdh commented Nov 19, 2012

Yes. This plugin needs this badly. Please merge!

@ScottIngram
Copy link

This feature is critical to our project. I just merged the patch into my local copy, but of course that will be clobbered when we launch to production. I suppose I could simply fork your plugin and abandon the original. Great plugin, otherwise.

@tednaleid
Copy link

That's what I've done on the last few projects, just forked locally and used it as a local plugin just to get this patch in.

Looking forward to switching over to the asset-pipeline plugin as the entire resources infrastructure has pretty much been left for dead.

Appreciate the work that was put into all of this originally, but control really needs to be transferred if none of the current committers are willing to do even basic maintenance.

@divideby0
Copy link

Our progression over the last year has been from resources -> asset pipeline -> dedicated grunt build. It's not for everyone but once you get over the initial hurdles of setting up node/npm, I've found grunt to be a much more traveled path for these sorts of things.

@tednaleid
Copy link

@divideby0 agreed. Grunt with require.js is a great combination that I used on my last project. Current project has a bunch of existing code to maintain so we can't go there (yet), but for greenfield projects that's a really good choice IMO.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants