Webpack Encore: A Party for your Assets

Hey Juan Miguel Ardissone

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!

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

Victor Bocharsky

Perfect, thanks a lot,

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!

Hi,
do you think that we absolutely have to read the preview course "Webpack for Module Loading Awesomeness" before this one, to understand webpack-encore ? Or it's not required
Thanks !

@weaverryan need an answer please :) I am impatient to buy the course

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!

Hi there! Thank you very much for your courses about ECMAScript6 and Weback/Webpack Encore! But there is one thing I think about: In the first tutorial you explained a lot about babel to compile new JS to older browsers. In the Webpack Encore course you did‘t talk about babel anymore. So my question is if it isn‘t still necessary to compile new JS with babel when using Webpack Encore? Maybe because this functionality is already included automatically? Or if not: what would be the best practice to compile JS with babel when using Webpack Encore? Thanks a lot for your help and advices!!!

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

Hey Adrian Szuszkiewicz!

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!

Hi guys - one question - why you require everything with --dev parameter? Isn't jquery module needed in production? I really don't get it :)

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 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!

Looking forward to this! I've just found Webpack Encore and this weekend I've plugged it into my Sculpin site, a Symfony app for my local PHP user group, and a couple of Drupal sites. :)

Hey Pilou,

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

Cheers!

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

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 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/.... 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/.... 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!

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.

With SF4 released, we really need this !
Can't wait.

Okay, I now understand. Thanks, guys!

Best Regards!

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!

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.

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!

Hi, weaverryan!
Thanks for Your tutorials, they are great!

PhpStorm can't recognise webpack.config.js:
"Can't analyse webpack.config.js: coding assistance will ignore module resolution rules in this file. Possible reasons: this file is not a valid webpack configuration file or its format is not currently supported by the IDE".
What am i doing wrong with PhpStorm settings?
Thanks!

Best Regards :)

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

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

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!

weaverryan Are we there yet? ;)

:)

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

Great! I started using Encore a couple of days ago, it's amazingly easy to setup, I'm excited to learn deeper from its creator! Thank you Ryan and good luck!