SymfonyCasts stands united with the people of Ukraine
gstreamer0.10-ffmpeg
gstreamer0.10-plugins-good packages.
Ok team: just one more thing to talk about: how the heck can we deploy all of this to production?
Well, before that, our files aren't even ready for production yet! Open the public/build/ directory. If you open any of these files, you'll notice that they are not minified. And at the bottom, each has a bunch of extra stuff for "sourcemaps": a bit of config that makes debugging our code easier in the browser.
We get all of this because we've been creating a development build. Now, at your terminal, run:
yarn build
This is a shortcut for yarn encore production. When we installed Encore, we got a pre-started package.json file with... this scripts section:
| { | |
| ... lines 2 - 19 | |
| "scripts": { | |
| "dev-server": "encore dev-server", | |
| "dev": "encore dev", | |
| "watch": "encore dev --watch", | |
| "build": "encore production --progress" | |
| }, | |
| ... lines 26 - 28 | |
| } |
So, the real command to build for production is encore production, or, really:
./node_modules/.bin/encore production
Anyways, that's the key thing: Encore has two main modes: dev and production.
And... done! On a big project, this might take a bit longer - production builds can be much slower than dev builds.
Now we have a very different build/ directory. First, all of the names are bit obfuscated. Before, we had names that included things like app~vendor, which kind of exposed the internal structure of what entry points we had and how they're sharing data. No huge deal, but that's gone: replaced by these numbered files.
Also, if you look inside any of these, they're now totally minified and won't have the sourcemap at the bottom. You will still see these license headers - that's there for legal reasons, though you can configure them to be removed. Those are the only comments that are left in these final files.
And even though all the filenames just changed, we instantly move over, refresh, and... it works: the Twig helpers are rendering the new filenames.
In fact, you may have noticed something special about the new filenames: every single one now has a hash in it. Inside our webpack.config.js file, this is happening thanks to this line: enableVersioning():
| ... lines 1 - 2 | |
| Encore | |
| ... lines 4 - 45 | |
| // enables hashed filenames (e.g. app.abc123.css) | |
| .enableVersioning(Encore.isProduction()) | |
| ... lines 48 - 76 | |
| ; | |
| ... lines 78 - 79 |
And check it out, the first argument - which is a boolean of whether or not we want versioning - is using a helper called Encore.isProduction(). That disables versioning for our dev builds, just cause we don't need it, but enables it for production.
The really awesome thing is that every time the contents of this article_show.css file changes, it will automatically get a new hash: the hash is built from the contents of the file. Of course, we don't need to change anything in our code, because the Twig helpers will automatically render the new filename in the script or link tag. Basically... we get free file versioning, or browser cache busting.
This also means that you should totally take advantage of something called long-term caching. This is where you configure your web server - like Nginx - to set an Expires header on every file it serves from the /build directory with some super-distant value, like 1 year from now:
server {
# ...
location ~ ^\/build\/ {
expires 365d;
add_header Cache-Control "public";
}
}The result is that, once a user has downloaded these files, they will never ask our server for them again: they'll just use their browser cache. But, as soon as we update a file, it'll have a new filename and the user's browser will ask for it again. It's just free performance. And if you got a step further and put something like CloudFlare in front of your site, your server will receive even less requests for your assets.
Now that we have these, optimized, versioned files, how can we deploy them up to production? Well... it depends. It depends on how sophisticated your deployment is.
If you have a really simple deployment, where you basically, run git pull on production and then clear the Symfony cache, you're probably going to need to install node on your production server, run yarn install, and then run yarn build up on production, each time you deploy. That's not ideal, but if you have a simple deployment system, that keeps it simple.
Tip
We show this on practice in our Animated Deployment with Ansistrano course.
If you have a slightly more sophisticated system, you can do it better. The key thing to understand is that, once you've run yarn build, the only thing that needs to go to production is the public/build directory. So you could literally run yarn build on a different server - or even locally - and then just make sure that this build/ directory gets copied to production.
That's it! You don't need to have node installed on production and you don't need to run anything with yarn. If you followed our tutorial on Ansistrano, you would run yarn wherever you're executing Ansistrano, then use the copy module to copy the directory.
Ok, that's it! Actually, there are more features inside Encore - many more, like enabling TypeScript, React or Vue support. But getting those all going should be easy for you now. Go try them, and report back.
And, like always, if you have any questions, find us in the comments section.
All right friends, seeya next time.
Hey gcob!
I really appreciate the nice words *and* the feedback / idea ❤️. About the lazy-load optimized image, I *do* think that image optimization would have been a good topic to talk about. We have a pull request to add support to Encore directly - https://github.com/symfony/... - but I need to actually review it - things are especially busy these days ;). But can you tell me more about the lazy-load part? Are you referring to when images are loaded on-demand (e.g. as the user scrolls near them)? Or something else? I just want to make sure :).
Cheers!
Hi Ryan,
I really appreciate that you took the time to reply even with these busy days ;) . And thanks for sharing the pull request, that is one important part of the optimisation I was thinking.
For the lazy-load part, it would be 3 important points :
1 - As you already mentioned, it would load the images on demand.
2 - Matrix images should be pre-processed in multiple sizes (mostly mobile, tablets, laptops and desktops for a large image.) In my opinion, it should be the client side to <i>decide</i> which image size to download rather than the server side, because JavaScript can determine a screen size and and server cannot. This is why the first images to load on the screen also need the lazy-load part: JavaScript need to <i>check</i> the screen size before <i>asking</i> the server for the right image. In this point, I use Grunt to build and minify every images in each sizes when adding them to a project. I use Bootstrap sizes to be constant.
3 - Because webp is always lighter than others matrix images types, each matrix images should have a webp version and its original for compatibility. Again, JavaScript is better to <i>know</i> if the client can read webp images rather than the server, so the lazy-load script can <i>ask</i> for the right image type.
In short and to give an example, a large image would have 9 versions of itself : image.original.jpg, image.xs.jpg, image.xs.webp, image.s.jpg and so on. A user can now download the right image size and type for his browser at the right time to save loading time and bandwidth!
I want to mention one last point: the reason I felt lazy-load images was missing to your tutorials, appart hearing you telling awesome jokes, giving us great advice, for all the extra-learning and making programming super fun (I can hear people telling me that I am a “lèche-botte”), is that Webpack Encore is a powerful tool and it is already ahead for optimisation in many ways, so it would be a huge part missing to not include image process.
One last thing: it is by using the Chrome Audits tool that I tweaked my client-side optimisations knowledge. I think sharing this super cool tool could be also very nice for the other developers :D .
I hope you’ll find this topic interesting! As I already mentioned, keep the great job. By the way, I live in Canada and as you said in a previous class, poutine is great ;)
-Your fan, Jacob.
Hey gcob!
Great information here - I would *love* to have something like this work out-of-the-box, as I'm sure it would normally require quite a lot of setup to get working. But if you *could*, what an awesome optimization. It looks like 2 separate parts:
A) The lazy-loading part
B) The "responsive image" part where you have multiple image sizes
Part (A) I think can't be done by Encore because it's up to your JavaScript to be loading those images lazily. That's not a good or bad thing - this is a fairly common problem to solve. But solving it would be different in a "traditional" server-side-loaded app vs React vs Vue, for example.
Part (B) *would* be something you could with with Webpack. But, I see very little support for this. I only find these 2 Webpack modules - https://www.npmjs.com/packa... and https://www.npmjs.com/packa... - the second is *fairly* popular, but hasn't had a release in 15 months (that's a decade in Node land). I was surprised by that. So, Encore could in theory integrate that second library... but we try to leverage best practices instead of "forging our own way". I'm just simply surprised that there's not more conversation on this topic. I wonder if you have any thoughts on this.
> By the way, I live in Canada and as you said in a previous class, poutine is great ;)
Ha! SO glad you caught that - I've had the pleasure to enjoy it *just* a few times... but what's not to like? :D
Cheers!
Hi.
Thank you very much. Symfonycasts courses are the best courses I have ever used :)
Can you recommend any tutorial on how to Deploy php / symfony application to your own server? How to deploy for multiple copies of an application on a single server (saas)? :)
Currently my deploy is manual copying via ftp client, I want to change that, automate it :)
Hey Lechu85,
Thank you for the kind words about SymfonyCasts tutorials! Yeah, we do have a tutorial about deploying, I'd suggest you to check out this Ansistrano course: https://symfonycasts.com/sc... - it's based on Ansible, and even if it's recommended you know this tool, you don't required to know it. But in case you want to know more about Ansible too - we have a separate course about it too: https://symfonycasts.com/sc... . But you can totally skip it and start learning Ansistrano directly, it should not be too complex.
P.S. Yeah, deploying your app manually via FTP client is a bummer... people usually automate this process with a shell script to deploy automatically via SSH instead, and a long time ago we had such an automated shell script, but then we moved to Ansistrano :) Well, right now we do not use Ansistrano because moved from Amazon to SymfonyCloud that has its own deploy tool :)
Cheers!
Thank you very much, I'm starting learning Ansistrano. Maybe in the future I will also switch to symfony cloud :)
Hey Lechu85,
Awesome, good luck with Ansistrano - it's a great tool we all loved! As always, if you have any questions following the course - let us know in the comments below the video :)
Cheers!
How do I disable minifying in production? I want the understandable filenames and the pretty-formatted unminified code. I can't find any option in webpack.config.js or in the yaml files where it enables it for production. (Actually I don't understand why minification is still a thing: do the additional whitespace and newline characters really make a difference in download speed when all the transfers are going to be gzipped anyway?)
Hey Matteo S.!
I think you're the first person that's ever asked about this! First, about this:
> Actually I don't understand why minification is still a thing: do the additional whitespace and newline characters really make a difference in download speed when all the transfers are going to be gzipped anyway?)
Honestly, this is something I've wondered from time to time also. You finally pushed me to look into it. At least according to this site, https://css-tricks.com/the-..., gzipping is the MOST important by far. However, you get a slight improvement if you do both (but at least in the example, it is slight).
Minimization is hardwired into the "production" build of Encore because nobody has ever asked or made a case for it being disabled in the "production" build. The same is true for the filenames. In prod, many of the filenames - the split files specifically - change from things like vendor~bootstrap~....js to just 0.js. That's there to "protect" from exposing your filesystem structure via your filenames. It's a pretty standard thing in Webpack to do this (but leave the longer filenames for dev because they're more descriptive).
Btw, you CAN still (though I haven't done it before) dump sourcemaps in production - that is configurable.
So, this isn't exactly the answer you were looking for, but I hope it clarifies.
Cheers!
Thank you, that's actually quite the kind of answer I was looking for.
I hadn't realised the readable filenames in dev are based on file paths and I understand you wouldn't want that in production. I don't love them per se, but at least they tell me roughly "what file contains what", and _that_ is something I do want in prod as well as in dev. Actually I often get the impression that many people consider the gibberish filenames (and partly the minification too) as an "added bonus" in that they obfuscate things, making it more difficult to reverse-engineer the website for whatever malicious purposes (e.g. stealing your code or hacking - actually that's two pretty different scenarios). And I think that's a flawed approach: If one is really interested in protecting the intellectual property on their code (assuming that's a legitimate goal) they should rely on something way more robust than randomizing filenames and minifying code; and if security is the concern, well then even more so. I know that is not the philosophy behind these design choices, but it is the only reason I can think of that would make it so widely accepted to have garbled unintelligible filenames for css/js files, which to me is a complete abomination.
Hey Matteo S.!
> And I think that's a flawed approach
Totally agree! You can always reverse engineer that if you care enough. And if you have something to hide, someone WILL care enough ;)
Specifically, for the files in the "dev" built files, it is "kind of" a different situation. You can't hide your JavaScript code via obfuscation in any way. However, the filenames in dev mode contain details about your system that do *not* need to be exposed. Specifically, it contains the *source* file paths on your system. I can't really imagine how they would be sensitive, but this is information that does not *need* to be shown to the user (unlike the JavaScript itself), and so Webpack hides it in prod mode. It's probably not a big deal in reality, but hopefully that gives you some idea of why they do that.
Cheers!
Yes I get that. I wish there was an alternative to get readable/understandable/informative file names that were also "clean" and "nice" and suitable for production. If there was I'd advocate in favor of using that as the default for production (and actually, why not, for dev too). Short of that, for my own projects I'll use the dev names both for dev and production, and maybe in the future I'll look into generating my own file names.
Hey Matteo S.!
I understand :). This is something you can control via Webpack's output.filename and output.chunkFilename - https://webpack.js.org/conf... - but I don't remember exactly how that all works (it's been a LONG time since I put that code into Webpack Encore). Here is where we build the "output" Webpack key in Encore: https://github.com/symfony/...
Cheers!
Why do you say you don't need file versioning for development? I would appreciate if you can answer here if yu don't mind: https://github.com/symfony/...
Hey PhpFan!
Good question actually! Well, first of all, versioning obviously will take more time to compile your assets, also it modifies file names too - those things are not something you want for production I think, but it still depends. There might be more things I didn't think about or don't know right now... But, in theory, why not? You can definitely enable versioning for dev mode too for your project. It might be tricky to apply this change globally in the Symfony recipe for the reasons I mentioned above, but it's easy to do on per project basis. So, if you need this - please, just change this behaviour in your webpack.config.js file and that's it :)
I hope this helps!
Cheers!
"Those things are not something you want for production"?? Versioning IS enabled by default on production (and for obvious good reasons), we are talking about why it is not enabled on DEV by default.
The main reason one DOES want versioning on production IS that it modifies file names. So users that have the assets in their browser cache don't get the stale ones. And my point is I don't see how that doesn't apply in development. Stale cached assets are going to bite you in the a** at almost every page load during development. Sure I can enable that, but my point is why is it not the default when I'm obviously going to have to do that?
Perhaps your assumption is that while developing I'll turn off the browser cache? Or hit ctrl+Refresh all the time?
Hey Matteo S.!
I'm pretty sure I'm the creator or that Webpack code originally. So I've replied over on the conversation :).
Cheers!
Hi,
I have this error message "An exception has been thrown during the rendering of a template ("Could not find the entrypoints file from Webpack: the file
"/app/public/build/entrypoints.json" does not exist.")." on SymfonyCloud server. Normally all entrypoints are generated during cloud mounting ?
Have you a solution to this problem ?
Hey Stephane
That error usually happens when you forget to run install and compile your assets. If you have followed the course till here, you should have Yarn installed already, so just run yarn install and then compile the assets by running yarn dev
Cheers!
Hi Diego,
Thank to yours reply. I know that and I don't have this problem on mine local machine but the problem is on SymfonyCloud Server. On this server, I have only symfony deploy like command. no possible to do npm run build
Ohh, so you're using SymfonyCloud. That's even better! You have complete control of your deployment process but you have to do it in a specific way. I'll point you to the documentation, read the "Hooks" topic it's quite simple https://symfony.com/doc/cur...
but if you have doubts let me know
Cheers!
Thank for the link.
I think to know what I have this bug : I use npm 7 on my local machine with nodeJS 15 and this is no generated the yarn.lock file that it is use to SymfonyCloud to build the assets.
I don't know if it is possible to use npm on SymfonyCloud to build assets ?
Cheers.
Symfony in general works better with Yarn but you can also use NPM if you desire. I think you only have to add the npm install step in your "build" hook. Try this:
// .symfony.cloud.yaml
hooks:
build: |
set -x -e
(>&2 symfony-build)
npm install # This line may go before symfony-build - You may want to play with it and see how it goes.
Cheers!
Hi Ryan, thanks for your great tutorials! I have a question: I configured Encore for a website and when I check the performance of the website with Google's PageSpeed Insights I get the (usual) render-blocking resources problem. Is there a way to optimize that? I guess the best would be to async all resources and place the critical css in the html (with tools like critical) but it is not clear to me how to proceed. Thanks!
Hey Marco
I think what you can do to improve your rendering is to move to the bottom of the page all of your javascript. And, if you are not satisfied, then, you could do what you say about using "critical" and loading asynchronously the other non-important assets. I haven't used that library but it seems nice
Cheers!
Hello,
i have a problem i can't resolve when i run "yarn buil", the design of my site is not the same before and after i run this command, can you help me please?
Hey mickael lutin
What's the output you get when running yarn build? Do you get any error in Browser's console?
Cheers!
hi thank you for the reply,
I have no errors in any of the consoles, i have the message who say the build is successfully but no other bad messages.
Hey mickael lutin!
You mentioned:
the design of my site is not the same before and after i run this command
Can you explain this more? If all of your CSS is being processed through Encore, I would expect that your site would basically be unstyled before executing Encore and styled after. Or, are you saying that your design looks different between running yarn dev versus yarn build?
Let us know!
Cheers!
Thank you very much for this tutorial!
I have watched all the chapters, but after finishing this last chapter, the website says:
You've reached the end!
Looks like you skipped some chapters or challenges,
finish the course to earn your certificate.
If I click the <strong>Finish</strong> button, I am redirected to the course's index page, but I do not understand what I am missing...
Thanks!
Hey Anton Bagdatyev
If you go to the course overview or click on the chapter's list field on this page, you will see that all the chapters that you have fully watched has a little arrow to its left, if you see any without it, it means that you didn't finish watching it. You've to watch them all in order to get your certificate of completion.
Cheers!
Hello everybody. I have a problem when i run npm build. All my files in public\build (app.js / app.css / runtime.js) have no hash.
I can't deploy on Heroku, the error message in the log is :
[webpack.Progress] 100%
* ./pages/Homepage in ./assets/js/app.js
Entrypoint app = runtime.e468f142.js 0.6905f39e.css 0.84d563c1.js app.9d089ddf.css app.9edd022c.js
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! @ build: `encore production --progress`
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the @ build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /tmp/npmcache.W1Cld/_logs/2020-01-14T14_40_16_410Z-debug.log
-----> Build failed
I need more help. Thank you.
Hey Felix!
Sorry for the slow reply! This is not a nice error! Is this all the output that you see? It looks like it doesn't actually contain the error :/. Are you able to look into the log file to see more information?
All my files in public\build (app.js / app.css / runtime.js) have no hash
About this part, you will only have the versioning hashes when doing the "production" build of encore. The error above IS using the production built, but in case you're running a command locally, just double-check that you're running a production build if you want to see the version hashes. You should also have a line like this in your webpack.config.js file:
Encore
# ...
.enableVersioning(Encore.isProduction())
Cheers!
Hello! Thank you so much for this tutorial series. Made JS and CSS feel so much better to develop.
I have a question regarding assets used for admin routes. Is it possible to make assets available only to certain "ROLE_"s? It might not be critical information in the files, but I would rather as little as possible of the admin source be public.
Thanks!
Hey August S.
Thanks for your kind works :)
What I think you can do is to create an "admin" layout where you import the "main" assets that are used across the site and import the admin assets as well, but you will use that layout only on your admin pages. Does it makes sense to you?
Cheers!
I think I understand what you mean. I am already extending my admin.html.twig (where I have linked admin.js and admin.css) with my admin pages. The "problem" is that I can log out and still access the route to the asset and view them: i.e. mysite.com/build/admin.js is still accessible when not logged in.
Maybe this is an apache/nginx problem, but I'm wondering if there is some nifty Symfony solution even here?
Thanks!
While learning about Webpack Encore, also getting an understanding of Babel and PostCSS. Thanks a lot for creating Webpack Encore and this extensive tutorial which is very helpful.
I have one use case where I still don't know if I can (and should) use Webpack, which is whenever I need a 'php-variable' in my css or js. Right now what I do in those cases is create a <style> or <script> tag within the Twig template where I can use my css or js and also my php-variables. Perhaps this could also move to Webpack? I can't really think of how to go about this though.
Hey Dirk
If you need to pass a template's variable into a JS "entry point" you can do it via window object. We usually set some things on it (window object) and then on a js script, we just read it window.myData.value
Cheers!
Cheers ;) I'll give it a try. Is there also a solution for a template variable in CSS? For example I would use in my "'in-page-css":
background: url('{{ some_variable }}');
Hmm, I don't know a way to pass variables to a css file, probably you will have to keep those styles inlined in your template
Hi Ryan, i have a trouble. I use Bootstrap modal and .load() function to fill content modal window. When in remote content is encore_entry_script_tags i have in browser console error :<blockquote> [Deprecation] Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience.</blockquote>
What i do wrong ?
MY CODE :
main.html.twig
`
/...../
// modal window
<div class="modal fade" id="modal_ajax" tabindex="-1" role="dialog" aria-labelledby="modal_ajaxTitle" aria-hidden="true">
<div class="modal-dialog modal-dialog-scrollable" role="document">
<div class="modal-content">
<div class="modal-header">
<h5 class="modal-title" id="modal_ajaxTitle"> </h5>
<button type="button" class="close" data-dismiss="modal" aria-label="Close">
×
</button>
</div>
<div class="modal-body">
<div class="text-center"></div>
</div>
</div>
</div>
</div>
/...../
// the trigger
< a class="btn icon-btn btn-info pull-right" data-remote="true" data-toggle="modal" data-target="#modal_ajax" href="{{ path('admin_parameters_ajax_add') }}" >
<span class="glyphicon btn-glyphicon glyphicon-plus img-circle extom-gray"></span>
Dodaj parametr
< / a>
/..../
{% block javascripts %}
{{ parent () }}
{{ encore_entry_script_tags('has_modals') }}
{% endblock %}<br />in file has_modals.js<br />
import $ from 'jquery';
// technically, with enableSingleRuntimeChunk(), you can be lazy and
// not import bootstrap, because it was done in app.js
import 'bootstrap';
$(document).ready(function() {
$('a[data-toggle="modal"]').on('click', function(e) {
var target_modal = $(e.currentTarget).data('target');
var remote_content = e.currentTarget.href;
var modal = $(target_modal);
modal.off();
var modalContent = $(target_modal + ' .modal-content');
modal.on('show.bs.modal', function () {
modalContent.load(remote_content);
}).modal();
modal.on('hide.bs.modal', function () {
modalContent.html("<div class="modal-header"><h5 class="modal-title" id="modal_ajaxTitle"></h5><button type="button" class="close" data-dismiss="modal" aria-label="Close">×</button></div><div class="modal-body"><div class="text-center"></div></div>");
});
return false;
});
});<br />adminParametersAjaxAdd.html.twig<br />
<div class="modal-header">
<h5 class="modal-title" id="modal_ajaxTitle">Dodaj parametr</h5>
<button type="button" class="close" data-dismiss="modal" aria-label="Close">
×
</button>
</div>
<div class="modal-body">
{{ form_start(form, {'action': path('admin_parameters_ajax_add')}) }}
{{ form_end(form) }}
</div>
{{ encore_entry_script_tags('admin_parameters_ajax_add') }}<br />admin_parameters_ajax_add.js<br />
//import $ from 'jquery';
console.log("file admin_parameters_ajax_add loaded");
`
I see in console text file admin_parameters_ajax_add loaded but before is deprecated warning :(
Please help me .
Hey Hessuss,
Hm, looks like something in your code triggers that deprecation message. Do you have more context in your console about it? Like file / line in file where it was triggered? Probably it comes from $.ajax() call, this might be helpful for you:
https://stackoverflow.com/q...
Cheers!
// composer.json
{
"require": {
"php": "^7.1.3",
"ext-iconv": "*",
"aws/aws-sdk-php": "^3.87", // 3.91.4
"composer/package-versions-deprecated": "^1.11", // 1.11.99
"knplabs/knp-markdown-bundle": "^1.7", // 1.7.1
"knplabs/knp-paginator-bundle": "^2.7", // v2.8.0
"knplabs/knp-time-bundle": "^1.8", // 1.9.0
"league/flysystem-aws-s3-v3": "^1.0", // 1.0.22
"league/flysystem-cached-adapter": "^1.0", // 1.0.9
"liip/imagine-bundle": "^2.1", // 2.1.0
"nexylan/slack-bundle": "^2.0,<2.2.0", // v2.1.0
"oneup/flysystem-bundle": "^3.0", // 3.0.3
"php-http/guzzle6-adapter": "^1.1", // v1.1.1
"sensio/framework-extra-bundle": "^5.1", // v5.3.1
"stof/doctrine-extensions-bundle": "^1.3", // v1.3.0
"symfony/asset": "^4.0", // v4.2.5
"symfony/console": "^4.0", // v4.2.5
"symfony/flex": "^1.9", // v1.17.6
"symfony/form": "^4.0", // v4.2.5
"symfony/framework-bundle": "^4.0", // v4.2.5
"symfony/orm-pack": "^1.0", // v1.0.6
"symfony/security-bundle": "^4.0", // v4.2.5
"symfony/serializer-pack": "^1.0", // v1.0.2
"symfony/twig-bundle": "^4.0", // v4.2.5
"symfony/validator": "^4.0", // v4.2.5
"symfony/web-server-bundle": "^4.0", // v4.2.5
"symfony/webpack-encore-bundle": "^1.4", // v1.5.0
"symfony/yaml": "^4.0", // v4.2.5
"twig/extensions": "^1.5" // v1.5.4
},
"require-dev": {
"doctrine/doctrine-fixtures-bundle": "^3.0", // 3.1.0
"easycorp/easy-log-handler": "^1.0.2", // v1.0.7
"fzaninotto/faker": "^1.7", // v1.8.0
"symfony/debug-bundle": "^3.3|^4.0", // v4.2.5
"symfony/dotenv": "^4.0", // v4.2.5
"symfony/maker-bundle": "^1.0", // v1.11.5
"symfony/monolog-bundle": "^3.0", // v3.3.1
"symfony/phpunit-bridge": "^3.3|^4.0", // v4.2.5
"symfony/profiler-pack": "^1.0", // v1.0.4
"symfony/var-dumper": "^3.3|^4.0" // v4.2.5
}
}// package.json
{
"devDependencies": {
"@symfony/webpack-encore": "^0.27.0", // 0.27.0
"autocomplete.js": "^0.36.0",
"autoprefixer": "^9.5.1", // 9.5.1
"bootstrap": "^4.3.1", // 4.3.1
"core-js": "^3.0.0", // 3.0.1
"dropzone": "^5.5.1", // 5.5.1
"font-awesome": "^4.7.0", // 4.7.0
"jquery": "^3.4.0", // 3.4.0
"popper.js": "^1.15.0",
"postcss-loader": "^3.0.0", // 3.0.0
"sass": "^1.29.0", // 1.29.0
"sass-loader": "^7.0.1", // 7.3.1
"sortablejs": "^1.8.4", // 1.8.4
"webpack-notifier": "^1.6.0" // 1.7.0
}
}
Hi Ryan, thanks alot for all these super tutorials and being such a nice teacher. I used to be a Grunt fan before knowing about encore webpack and now I can’t wait to use it! With all the documentation out there and all the information you gave us, I know that it is possible for me and every one to build a project for our needs, but I felt that something is missing in your tutorials about encore and it is the image processing. For example, having a responsive lazy-load optimised image javascript module or something like that would have be more than awesome. I’m saying this because of all the extra learning we get following your tutorials that are priceless time savers and let’s not forget all the line of thought you tell us including the pros, cons and conclusions ;) Anyway, keep the great job! -Jacob