Basset serving development collections on production environment

[drbroad]

This is frustrating me so much I might have to kick a wide brimmed hat off a goose.

The problem:

• My hosting environment is shared and i cannot install gems. Because of this I use the PHP SASS and JsMin packages.*
• I REALLY want to use UglifyJS2 for all the goodness it provides, but because of the above issue i cant build a production collection on the server
• I use private repos on bitbucket for my version control
• I use capistrano for deployment. To try get around the production build issue i have created a cap task:

namespace :preflight do
  task :prepare_css do   
    %x{php artisan basset:build --production}
    %x{git add --all}
    %x{git commit -m "Uglify JS & Production CSS"}
    %x{git push origin}
  end
end

before "deploy:update_code", 'preflight:prepare_css'

• The purpose of this task is to run a production build locally, and then commit those file to bitbucket. (i could do this manually, but it just saves some user error). These files are confirmed on my bitbucket as being pushed successfully.
• When i test locally and force laravel into production mode - it correctly uses the minified, compressed and uglified CSS and JS
• Capistrano then moves the code from bitbucket to my server.I can confirm that that release/public/builds folder contains the generated production build files
• When the deploy has finished, i fire up my browser (i have a footer that displays some debug info - one of which is environment) and it shows production
• When i view the source it is serving the development assets.

Arggghhh!!

Its like the manifest is not seeing that the production files have been generated and is serving development assets. Again, i cannot run a php artisan basset:build --production on the server as it doesnt have gems, therefore no uglifyjs etc etc.

So: anyone got any ideas about why basset is not recognizing the production assets / where i should look for clues?

Help greatly appreciated (im so close to my ideal workflow!)

---

• Please don't tell me to change my hosting. That isn't a solution.

[jasonlewis]

The production environment set in the Basset config matches the one you've set?

You should just switch to Grunt though. I'm no longer supporting this package. On 31 Oct 2013 06:08, "drbroad" notifications@github.com wrote:

This is frustrating me so much I might have to kick a wide brimmed hat off a goose.

The problem:

• My hosting environment is shared and i cannot install gems. Because of this I use the PHP SASS and JsMin packages.*
• I REALLY want to use UglifyJS2 for all the goodness it provides, but because of the above issue i cant build a production collection on the server
• I use private repos on bitbucket for my version control
• I use capistrano for deployment. To try get around the production build issue i have created a cap task:

namespace :preflight do task :prepare_css do %x{php artisan basset:build --production} %x{git add --all} %x{git commit -m "Uglify JS & Production CSS"} %x{git push origin} end end

before "deploy:update_code", 'preflight:prepare_css'

• The purpose of this task is to run a production build locally, and then commit those file to bitbucket. (i could do this manually, but it just saves some user error). These files are confirmed on my bitbucket as being pushed successfully.
• When i test locally and force laravel into production mode - it correctly uses the minified, compressed and uglified CSS and JS
• Capistrano then moves the code from bitbucket to my server.I can confirm that that release/public/builds folder contains the generated production build files
• When the deploy has finished, i fire up my browser (i have a footer that displays some debug info - one of which is environment) and it shows production
• When i view the source it is serving the development assets.

Arggghhh!!

Its like the manifest is not seeing that the production files have been generated and is serving development assets. Again, i cannot run a php artisan basset:build --production on the server as it doesnt have gems, therefore no uglifyjs etc etc.

So: anyone got any ideas about why basset is not recognizing the production assets / where i should look for clues?

Help greatly appreciated (im so close to my ideal workflow!)

• Please don't tell me to change my hosting. That isn't a solution.

— Reply to this email directly or view it on GitHubhttps://github.com/jasonlewis/basset/issues/218 .

[drbroad]

You should just switch to Grunt though. I'm no longer supporting this package.

Yikes. Might want to put that on the front page. I ditched my laravel-guard workflow for Basset after I realized that wasn't supported. Looks like I will have to invest some time with grunt and creating my own tasks. Not quite so easy as 'just switching to grunt' however for most people. Then you get the headaches of ruby management. Conflicts with packages. Dead ends and frustrating terminal sessions ..but that's not for here.

I was about to answer this question earlier. It looks like the storage > meta folder that basset stores its fingerprinting in collections.json has a git ignore on all files. So even though I have one generated locally - it is never pushed to my git, never deployed with Capistrano and therefore no record that the production collections may have been built.

As a dirty work around i let git add the collections json as an exception. Not ideal, but until I get my grunt chops (and new hosting) it's going to have to do!

[jasonlewis]

Yeah I haven't had a chance to update the read me, sorry. On 31 Oct 2013 15:38, "drbroad" notifications@github.com wrote:

You should just switch to Grunt though. I'm no longer supporting this package.

Yikes. Might want to put that on the front page. I ditched my laravel-guard workflow for Basset after I realized that wasn't supported. Looks like I will have to invest some time with grunt and creating my own tasks. Not quite so easy as 'just switching to grunt' however for most people. Then you get the headaches of ruby management. Conflicts with packages. Dead ends and frustrating terminal sessions ..but that's not for here.

I was about to answer this question earlier. It looks like the storage > meta folder that basset stores its fingerprinting in collections.json has a git ignore on all files. So even though I have one generated locally - it is never pushed to my git, never deployed with Capistrano and therefore no record that the production collections may have been built.

As a dirty work around i let git add the collections json as an exception. Not ideal, but until I get my grunt chops (and new hosting) it's going to have to do!

— Reply to this email directly or view it on GitHubhttps://github.com/jasonlewis/basset/issues/218#issuecomment-27460759 .

[dustingraham]

I have also invested a significant bit of time into this package in the last couple months. A heads up would really be appreciated.

Does Grunt compile less stylesheets and all that as well?

I'm also getting frustrated about my production box not using the compiled builds. It builds fine. But then just serves the development files. I think monolog should log an info or notice when in production, about why it decides not to serve production files. I.E. "Fingerprint stale" "cache clear needed" "files need to be rebuilt" etc... Additionally, if the files need to be rebuilt, a note as to why would be helpful.

I run php artisan basset:build --env=production sometimes and even though I didn't change a file, it'll randomly rebuild it rather than saying no build required.

[marco-solare]

hey Jason, can understand you moving to grunt, however it's a bit sad for some people like me as I totally loved basset, invested some time (as the others) and I do not see an alternative in using sw that relies on node (just want to keep my architecture dead-simple). I'd say: basset definetely filled a gap! ruby- and node-based packages are no solution for folks like me...