Closed jpatters closed 10 years ago
Can you elaborate some more with details?
My application.js file looks like this:
// This is a manifest file that'll be compiled into application.js, which will include all the files
// listed below.
//
// Any JavaScript/Coffee file within this directory, lib/assets/javascripts, vendor/assets/javascripts,
// can be referenced here using a relative path.
//
// It's not advisable to add code directly here, but if you do, it'll appear in whatever order it
// gets included (e.g. say you have require_tree . then the code will appear after all the directories
// but before any files alphabetically greater than 'application.js'
//
// The available directives right now are require, require_directory, and require_tree
//
//= require_tree .
//= require script
In my package ServiceProvider.php I have:
public function boot()
{
$project_base = $this->app['path.base'];
$base = substr(str_replace($project_base, '', realpath(__DIR__ . '/../../assets')), 1);
\Event::listen('assets.register.paths', function($paths) use ($base) {
$paths->add($base . '/stylesheets', 'stylesheets');
$paths->add($base . '/javascripts', 'javascripts');
});
$this->package('<vendor>/<package>', 'theme');
}
This works when the environment is set to dev (property includes the script.js
file from workbench/<vendor>/<package>/src/assets/javascripts/script.js
but it does not get compiled in when in a production environment.
My css is setup in a similar way and works fine in both environments. I have //= require theme
in the application.css file and have a file at workbench/<vendor>/<package>/src/assets/stylesheets/theme.css
.
@bigfoot13442 hmm... so you are certain that assets.register.paths is being called right? By the way, this event listener went away as of 1.4. What do you get when you dd($paths) ? Do you see your new paths in there?
Also, if you are doing a package for asset pipeline, I would really recommend updating it to 1.4 and using
Event::listen('asset.pipeline.boot', function($pipeline) {
$config = $pipeline->getConfig();
$config['paths'][] = $base . '/javascripts';
$config['paths'][] = $base . '/stylesheets';
$pipeline->setConfig($config);
});
I am certain it is being called since the css is working and in the same function. Plus, js is working in dev. I'll post dd($paths) later.
I tried to update to 1.4 yesterday but it broke everything in php 5.3. I see that have been some bug fixes and you updated it to work with 5.3 so I might try and update again.
Thanks
dd($paths) outputs a lot of stuff but I assume this is the part you are concerned with:
["paths"]=> array(14) {
["app/assets/fonts"]=> array(1) {
[0]=> string(5) "other"
} ["app/assets/images"]=> array(1) {
[0]=> string(5) "other"
} ["app/assets/javascripts"]=> array(1) {
[0]=> string(11) "javascripts"
} ["app/assets/stylesheets"]=> array(1) {
[0]=> string(11) "stylesheets"
} ["lib/assets/fonts"]=> array(1) {
[0]=> string(5) "other"
} ["lib/assets/images"]=> array(1) {
[0]=> string(5) "other"
} ["lib/assets/javascripts"]=> array(1) {
[0]=> string(11) "javascripts"
} ["lib/assets/stylesheets"]=> array(1) {
[0]=> string(11) "stylesheets"
} ["provider/assets/fonts"]=> array(1) {
[0]=> string(5) "other"
} ["provider/assets/images"]=> array(1) {
[0]=> string(5) "other"
} ["provider/assets/javascripts"]=> array(1) {
[0]=> string(11) "javascripts"
} ["provider/assets/stylesheets"]=> array(1) {
[0]=> string(11) "stylesheets"
} ["vendor/futurewebsolutions/passport-australia/src/assets/stylesheets"]=> array(1) {
[0]=> string(11) "stylesheets"
} ["vendor/futurewebsolutions/passport-australia/src/assets/javascripts"]=> array(1) {
[0]=> string(11) "javascripts"
}
}
The last 2 entries are the ones that get added by my service provider.
So you said it is working in dev but not prod? What is breaking? The javascript code? Are you doing concat in dev?
In your config.php also, try doing this...
'client_cache' => false
This will keep the etag stuff from kicking which I've striped out of 1.4 because it was causing more harm than good.
@bigfoot13442 did that help resolve your issue?
@kdocki sorry, i've been away for a few days. I'll test this out tomorrow.
@bigfoot13442 I updated the v1.3 tag to have this client_cache
as false because it seems to be causing more harm than good.
@bigfoot13442 any update?
please re-open if the issue is not resolved.
Using v1.3 (still on laravel 4.0.x) js paths that are registered in a package that I have created, do not end up in the compiled version in production.
Everything works in dev.