Webpack Encore: A Party for your Assets

Cheers! Thanks for the nice comment :)

Hey @pasquale_pellicani ,

This course is a legacy course, you can see it when you open any video page in it. And it links to the updated course which is https://symfonycasts.com/screencast/webpack-encore . So, yes, definitely take a look at the updated tutorial instead: https://symfonycasts.com/screencast/webpack-encore :)

Cheers!

Hey @Is_g!

It's been a LONG time since we made this transition, so I can't remember exactly! I think the transition will probably need to be done "all at once". With Assetic, you basically list all of the JavaScript (or CSS files) you want to be combined via the javascripts/stylesheets tag. So probably the simplest thing would be to:

A) For each javascripts tag, create a new webpack entry. For example, for the javascripts tag in base.html.twig, I'd make an entry called "app".
B) In the app.js file, import all of the files that were previously in the javascripts blocks - e.g.

// assets/app.js
// import the files from your old javascripts block
import './first_file';
import './second_file';

C) Replace the javascripts tag with encore_entry_script_tags('app').

For the stylesheets in base.html.twig, I would also import those from assets/app.js:

// assets/app.js
import './first_file';
import './second_file';

import './stylesheets/app.css';

Then in app.css:

@import './first_file';
@import './second_file';

And use encore_entry_link_tags('app').

Let me know if that makes sense :). Once you have this working, THEN you can start to refactor your JavaScript files to properly "export" values and then import them - i.e. once you have things working, THEN you can think about taking advantage of Webpack's ability to import/export files.

Cheers!

Hey Nacer,

Good question! Well, it's not required, and most of the job Webpack Encore do for you, in some cases you need to see some examples and copy/paste some code and that's it. But if you want to completely understand how Webpack Encore works - you need to know Webpack, because Webpack Encore is just a nice wrapper around Webpack that tries to make things much simpler from the developer perspective. And if you need some complex things, it's good to know webpack because Webpack Encore capabilities are limited yet, it's a young library. So some complex stuff you might need to do directly with Webpack.

In short, you *can* start with Webpack Encore, and if you would need more information or would like know more about internals - complete another one course about Webpack.

I hope this helps!

Cheers!

Which other course about Webpack internals, in order to fully master it without using Encore, would you advise?

Hey Anton,

We have Webpack Encore course: https://symfonycasts.com/sc... - and we recommend to use Encore instead of using Webpack directly. Actually, Webpack Encore is just a simple wrapper around Webpack that makes your life easier, especially if you're a backend developer. But it also make frontend developer's life easier as well. But in case you're interested in learning internals and know a bit more about Webpack and how it works - I'd recommend you to look at another course: https://symfonycasts.com/sc...

I hope this helps!

Cheers!

Thanks Victor! In the last link you gave me, it is mentioned: This tutorial covers Webpack 3, and Webpack 4 has now been released. But don't worry! The vast majority of the concepts are still the same. So, if you want to learn Webpack & module loading, you're still in the right place. The biggest differences are in the CommonsChunkPlugin area.

Will you ever release a course like that dealing with Webpack internals and pitfalls without Encore, but for Webpack 4 instead of Webpack 3 and using SplitChunksPlugin instead of the old CommonsChunkPlugin? Thanks!

Hey Anton Bagdatyev!

> Will you ever release a course like that dealing with Webpack internals and pitfalls without Encore, but for Webpack 4 instead of Webpack 3 and using `SplitChunksPlugin` instead of the old `CommonsChunkPlugin`?

I can answer that :). Probably.... no ;). This "Split chunks" thing is a *super* complex part of Webpack... and it's *likely* not one that you will ever need to worry about. If you want to be extra comfortable with Webpack so that you're *really* comfortable with Encore, I'd still recommend the Webpack tutorial that Victor linked to. It *is* becoming more out-of-date, but it will show you how Webpack works and how its configuration system works. You'll then be much more comfortable with how Encore is (basically) just a Webpack config generator :). Oh, but skip the CommonsChunk stuff entirely - that is now SUPER old.

Cheers!

OK, thank you very much!

Hey Anton,

Yes, it might happen in the future, but unfortunately not soon. We're actively working on some new tutorials right now (even one JS tutorial), and have some pending tutorials as well. In other words, a lot of good new stuff is coming, but not Webpack yet, so I can't say when it might be released.

Anyway, the content of that Webpack course is still valid, and the difference is minor. Moreover, we have some notes in that course that would help you if you're using Webpack 4.

And as always, if you have any problems following the course - please, let us know in the comments below videos and we will try to help you!

Cheers!

Great, thanks!

victor

Perfect, thanks a lot,

Cheers!

Hey Daniel Kronika!

Very good attention to detail! Yes, this it is still necessary to transpile with Babel (actually, I'll say more about this in a moment). And YES, with Encore, it happens automatically :). Encore automatically transpiles things using the Babel "env" preset and includes some configuration (https://github.com/symfony/... that tells Babel to transpile any code needed so that your JavaScript is compatible with all browsers that are used by more than 1% of the population.

So actually, back to this question:

> is it still necessary to compile new JS with babel when using Webpack

This answer I gave above is yes. However, it really depends on your users. If your users use newer browsers, you can tweak the 1% config (that I listed above) so that *less* features are transpiled. Basically, as your users use newer browsers, less features must be transpiled. Transpiling makes your final JS a little bit larger. I leave the 1%, but if you want, you can look at your analytics, and use the Encore.configureBabel() method (https://github.com/symfony/... to tweak that "browsers" config to some other value.

I hope that clarifies! Cheers!

Ryan. This means that we can use all ES6 features and webpack will transpile it?

Hey micayael

If you are using Webpack by yourself, then no, you will have to setup babel to actually do it, but if you are using Encore, then you don't have to :)

Cheers!

Hey Niumis,

Thanks for your feedback!

What are you doing to get this error? Eventually, Encore.getWebpackConfig() should return a valid webpack config. Do you export the result like: module.exports = Encore.getWebpackConfig();? Do you have any JS errors in Chrome's Console when loading a page which use Webpack features?

Cheers!

Hey, Victor!

Thank you for reply!

I just load symfony-demo app into PhpStorm. Nothing change in project and PhpStorm preferences. PhpStorm says "Can't analyse webpack.config.js: ..." and "Unresolved function or method" in all functions in Encore block. Maybe need configure PhpStorm or something else?
Sorry for my bad English...

Cheers :)

P.S. Chrome's Console it's ok, nothing errors found.

Hi, here's how I did it to avoid PHPStorm error : https://gist.github.com/plf...

Hey Pilou,

Wow, what a tricky workaround! Thank you for sharing it with others! :)

Cheers!

We have an issue open on the official Encore repository about this problem in PhpStorm. It CAN be ignored, but you actually lose auto-completion for any aliases or resolve paths defined in your webpack config. If you care enough, the gist above is a bit ugly, but honestly, works great :).

Hey niumis!

So, let me answer this in 2 parts :).

1) "Can't analyse webpack.config.js": this is nothing to worry about. PhpStorm recently added webpack.config.js support. But since Encore takes care of all of the complex stuff for you, it's ok that PhpStorm doesn't help us.

2) "Unresolved function or method": this is indeed a bug in Encore. It doesn't affect anything, but due to a change we made a few months ago, PhpStorm now has a hard time auto-completing methods. It's something we should be able to fix in Encore pretty soon.

Cheers!

Okay, I now understand. Thanks, guys!

Best Regards!

weaverryan , "this is nothing to worry about"? "it's ok that PhpStorm doesn't help us"?
But it's more like "Encore stands in the way of PhpStorm", not "PhpStorm doesn't help us".
In current implementation, when you use Encore in webpack.config, you are _forced_ to use it _only_ via Encore bin. If you try to use such config in any way, except through Encore, it will just complain "Blah blah blah Are you trying to use index.js directly? Rly? Blah blah...", 'cause Encore's webpack config builder requires some webpack runtime configuration data, which is provided by Encore's bin script. Webpack's config files, in general, are supposed to be self-contained to be interusable with other tools (as their only purpose is to provide build config object, no side effects are expected). With Encore, it will be only usable by Encore itself.
Thus, no Webpack integration with ESLint, no Webpack integration with PhpStorm, no Webpack integration with, well, anything. Except Encore, ofc. Not critical, sure, but being unable to use, f.e., Webpack's resolver config is a cons.

Don't get me wrong, Encore is definitely a great tool, but mostly if your project is more backend'y, than frontend'y. Not so great for SPA projects and alike, or for projects that have extensive client-side part, 'cause it breaks integration with some must-have tools in frontend dev toolkit.

Is it going to be fixed, somewhen, somehow?
Thanx in advance.

Hey there!

Sorry for my slow reply - the holidays :)

First, hmm, I suppose you could say that about Encore standing in the way of PhpStorm :). I disagree, but fair enough! Encore is a webpack config generator. So, if you decide to use Encore, then you're no longer writing webpack config directly anymore. This means that any tools that help with this config - e.g. PhpStorm - will not work. Btw, the reason we require the encore config is because we need to capture certain flags passed to encore so that we can adjust our generated config. And actually, you can work around this: https://github.com/symfony/webpack-encore/pull/115. Perhaps this just isn't documented well enough?

(Encore is ...) not so great for SPA projects and alike, or for projects that have extensive client-side part, 'cause it breaks integration with some must-have tools in frontend dev toolkit.

But I am curious about this. What tools do you mean that won't work? Does the configureRuntimeEnvironment() method I listed above solve these issues?

Is it going to be fixed, somewhen, somehow?

You're referring to the bug about the PhpStorm auto-completion. We have an issue on it: https://github.com/symfony/webpack-encore/issues/151. I hope we'll fix it soon - or someone in the community can :). I've had to focus on other parts of Symfony for the Symfony 4 release, but will come back to Encore for some great changes soon.

Cheers!

Yay, thats really what I was searching for!

> Perhaps this just isn't documented well enough?
Definitely. There's just _nothing_ in the docs, about the possibility to being able to keep webpack configs at least semi-autonomous.

> What tools do you mean that won't work?
Any tools, that are relaying on webpack resolvers to do their job. F.e. ESLint+vue-plugin wouldn't be able to process ".vue" files, it would stumble upon trying to resolve imports in that files. That's not to mention aliases, externals, etc. Same goes for some testing tools (had a hard time trying to configure Wallaby+jasmine). Also, PhpStorm becomes unavailable to resolve aliases in imports (which is a thing on itself), and thus type-completion/hinting becomes less-precise. Also, it becomes quite a riddle to try to configure ESLint's rule 'import/extensions'. etc. etc.

> You're referring to the bug about the PhpStorm auto-completion.
No, that one is bearable, I was referring to webpack configs becoming unusable outside of Encore's bin in general. As far as I can tell, '.configureRuntimeEnvironment()' would be enough to fix that, thank you very much for the guidance!

Hey here!

> > Perhaps this just isn't documented well enough?
> Definitely. There's just _nothing_ in the docs, about the possibility to being able to keep webpack configs at least semi-autonomous.

I've got an issue open to fix this :).

> > What tools do you mean that won't work?
> Any tools, that are relaying on webpack resolvers to do their job. F.e. ESLint+vue-plugin wouldn't be able to process ".vue" files, it would stumble upon trying to resolve imports in that files. That's not to mention aliases, externals, etc. Same goes for some testing tools (had a hard time trying to configure Wallaby+jasmine). Also, PhpStorm becomes unavailable to resolve aliases in imports (which is a thing on itself), and thus type-completion/hinting becomes less-precise. Also, it becomes quite a riddle to try to configure ESLint's rule 'import/extensions'. etc. etc.

Yes, now I'm more aware/understanding about the PhpStorm aliases issue. We have any issue open on this too - but, of course, this could be tricky to fix :/.

About ESLint+vue-plugin, can you tell me more about this? Why does Encore make this a problem versus how Webpack works?

> > You're referring to the bug about the PhpStorm auto-completion.
No, that one is bearable, I was referring to webpack configs becoming unusable outside of Encore's bin in general. As far as I can tell, '.configureRuntimeEnvironment()' would be enough to fix that, thank you very much for the guidance!

Awesome :).

Cheers!

Hey Adrian!

Great question - I get this a lot actually. Basically.... it doesn't matter :). But, technically, everything should be done as a dev dependency. The reason is that you actually do NOT need the jquery module on your production server: you only need the jquery module to exist during your *build* process so that you can create the final .js and .css files that are needed on production. In fact, we don't need ANY of the Webpack, Encore or node stuff on production at all.

But, like I said, it doesn't really matter. It would only matter in the following situation: you are actually building a Node web app that WILL be running on your production server in addition to using Webpack Encore. In that case, the modules needed for the web app should be required without --dev, but the Webpack Encore stuff *should* have --dev. That would allow you to include only the "Node web app" dependencies on production. Super weird edge-case... but there it is ;)

Cheers!

Ok, you're right, thanks Ryan! :)

Woohoo! Really glad to hear about your success already - that makes my day! More to come :)

:)

Hey Zorpen!

Bah, not yet! With the Symfony 4 release, we need to get the first big Symfony tutorial out first. But this will be next! I'm hoping to release a lot of good stuff in a few weeks / January. Thanks for your patience!

Cheers!

Thanks weaverryan
Will Joyful Development with Symfony 4 be some kind of fork of AquaNote, or brand new project?
Either way - can't wait!

Brand new project :) And we *just* designed it: "Deep Space Junk". More soon....