Skip to content

[5.8] Allow configuring a default manifest directory #27701

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

Closed
wants to merge 3 commits into from
Closed

[5.8] Allow configuring a default manifest directory #27701

wants to merge 3 commits into from

Conversation

CupOfTea696
Copy link
Contributor

@CupOfTea696 CupOfTea696 commented Feb 27, 2019

This PR depends on laravel/laravel#4957.

This PR enables users to set a default manifest directory for all calls to the mix helper, so that they don't have to pass a second parameter to it every time. It also makes it less likely that a user will forget to pass the manifest directory to the mix helper. An additional benefit is that, if they would ever change this path, they can now change it in a single location, rather than having to go through all their views. It is also makes it easy to change this path in different environments.

This PR doesn't break any existing features. It only adds one additional line to the Mix class and doesn't change its signature. The behaviour of the helper function stays the same if the configuration value isn't set.

Example usage:

In webpack.mix.js

mix.setPublicPath('public/assets');
mix.sass('resources/assets/scss/app.scss', 'public/assets/css')
    .version();

In config/app.php

<?php

return [
    ...

    'manifest_directory' => env('MANIFEST_DIRECTORY', ''),

    ...
];

And then finally, in any view file:

<link rel="stylesheet" href="{{ mix('css/app.css') }}">
<!-- renders to <link rel="stylesheet" href="/assets/css/app.css?id=123"> -->

Previously, you'd have to use the following every time you used a mix asset:

<link rel="stylesheet" href="{{ mix('css/app.css', 'assets') }}">

@ludo237
Copy link

ludo237 commented Feb 27, 2019

Wait... I never had to pass the manifest directory inside mix function 😕

@CupOfTea696
Copy link
Contributor Author

CupOfTea696 commented Feb 27, 2019

@ludo237 You don't have to if you let it compile to the default directory.

I personally always compile my assets to public/assets as to not clutter my public directory too much.

@ludo237
Copy link

ludo237 commented Feb 27, 2019

Thanks for the explanation, now it makes sense

@timacdonald
Copy link
Member

Because mix is now bound to the container, you should be able to do this without any config. Lemme see if I can put together an example.

@timacdonald
Copy link
Member

timacdonald commented Feb 27, 2019

Yea, you could just do this in your app by swapping out the mix implementation with an extended class that has the default value, instead of introducing a framework wide config variable.

Take a look at this slightly adjusted, and passing, version of your test.

public function testMixWithConfiguredManifestDirectory()
{
-    app('config')->set(['app.manifest_directory' => 'mix']);
+    $this->swap(Mix::class, new class extends Mix {
+        public function __invoke($path, $manifestDirectory = 'mix') {
+           return parent::__invoke($path, $manifestDirectory);
+        }
+    });

    mkdir($directory = __DIR__.'/mix');
    $manifest = $this->makeManifest('mix');

    $result = mix('unversioned.css');

    $this->assertSame('/mix/versioned.css', $result->toHtml());

    unlink($manifest);
    rmdir($directory);

-    app('config')->set(['app.manifest_directory' => '']);
}

That allows you to set a default value for the mix directory. You could just swap the mix singleton in you app service provider and this should work perfect.

@taylorotwell
Copy link
Member

Thanks for your pull request to Laravel!

Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.

If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!

If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.

@CupOfTea696 CupOfTea696 deleted the feature/configurable-manifest-path branch March 28, 2019 16:54
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.

4 participants