CommonsChunkPlugin: Shared/Vendor Entry

I'm really enjoying this course. I've been wanting to improve my javascript as well as get some exposure to webpack, and it's entertaining! But... two things are bothering me: 1) I'm failing to see how a .css file is a dependency of a .js file, as in login.js, for example. In my mind both of those files are dependencies of the template. 2) When we removed jQuery from the template script tag, I was like "Yes, I like where this is going". But we've just added vendor.js in it's place. I'm not really sure we're solving anything; just making things more complex...

Hey tomchkkk!

Ah, very interesting "botherings" :).

1) Hmm. Ok, I can understand how you think of both your .js file and your .css file as a dependency of your template. And, part of the reason that you think this way vs "Webpack" thinks a different way is that the creators of webpack typically have more of a single-page-app mentality, where your JavaScript is actually responsible for *creating* your markup - and there really is no template.

But let me see if I can just "spin" this idea slightly. Think of every page on your site as its own "app": with HTML (from your template), JavaScript & CSS. If you think about it this way, the HTML, CSS & JS are all dependencies of this abstract idea of an "app" - you need them all to make everything work smoothly. In a single-page app, your JavaScript is the absolute heart - it *is* the app - it even builds the markup. In a more traditional app, we still have templates, so the perfect "your app is your JavaScript" idea isn't quite as clean. So, we can't "include" the markup in the JavaScript file - it needs to live in its own template. But we *can* still (at least) include the CSS from the JavaScript "app". The final feeling isn't quite as clean and awesome as a single-page-app, but this is where that mentality comes from.

And, some of the bigger reasons are just practical ones: by processing your CSS through Webpack, you get minification, and the ability tp "pull things out" into your vendor entry (which is part of your next question).

2) This is another great point. But, I want to look at each step independently, so we can see what IS and what is NOT necessary.

The problem with putting jQuery as a script tag is that this creates a global jQuery object. As you know (because you've been watching the tutorial!) this means that we just need to "hope" that jQuery was already included whenever we reference the $ variable.

So, the most important change we're making is that we can now properly require jQuery wherever we need it, instead of assuming it will be globally available. This is the *really* important thing that I want us to think about first, because *it* is the bigf win! We can require variables instead of globals! :)

Of course, then you get to this chapter. Up to this point, we've written very clean, simple code: if you are in a .js file and you need jQuery, require it. Boom! How nice is that? But now, our "overall" build is not optimized - jQuery is being included in too many places. So, unfortunately, yes, this part adds a bit of complexity because you need to think a bit about your "overall" build so that you can optimize it. BUT, I want to be very clear about something: when we require jQuery in vendor.js, this does NOT make it a global variable - it simply makes sure that this file is packaged in vendor.js, but NOT also in all of our other entry files. For example, if you required jQuery in vendor.js, but then in another entry file, just started trying to use the "$" variable, it would fail! You are still responsible for requiring everything you need. The vendor.js trick is just a build optimization (caveat to this - if you followed this chapter - https://symfonycasts.com/sc... - then you actually CAN reference $ and jQuery anywhere without requiring it first. That's actually a bummer, and you shouldn't rely on it. The point of that chapter was to allow "badly written" libraries to cheat. But, it also allows us to cheat, unfortunately).

Phew! By the way, in the next version of Webpack (which was released a few months ago), this CommonsChunkPlugin went away for a different solution to this problem. I won't say more about that new solution here (because it deserves its own video probably!) but it will be supported in the next version of Webpack Encore, which I hope to release soon. It's called "split chunks" - and you can read about it now, or how to use it with Encore soon.

Cheers and keep going! Webpack is not a perfect world, but it IS a MUCH better world.

Thanks, weaverryan for going to the effort of writing such a thorough response.

Well rats. WebPack V4 removed CommonsChunkPlugin() and I have been unable to figure out how to get its replacement (SplitChunksPlugin()) to work.

I've added it to my webpack.config.js file and specified chunks: 'all', but to no apparent avail.
I have no new output files and my other output files are the same size as before.

An update here in the Conversation would be most welcome.

Thanks.

Okay. After much digging around, I've realized that the replacement is actually just a new configuration section, specifically optimization.splitChunks.

I've added this to my webpack.config.js file:

optimization: {
    splitChunks: {
        chunks: 'all'
    }

This appears to result in the creation of additional chunks with the common modules:

$ ./node_modules/.bin/webpack
Hash: ec802fcda25872729d3a
Version: webpack 4.2.0
Time: 4312ms
Built at: 3/26/2018 9:05:35 AM
                           Asset       Size                        Chunks             Chunk Names
                       layout.js   2.44 MiB                        layout  [emitted]  layout
        dumbbell-mini-41a097.png  684 bytes                                [emitted]
  fontawesome-webfont-912ec6.svg    434 KiB                                [emitted]
  fontawesome-webfont-b06871.ttf    162 KiB                                [emitted]
fontawesome-webfont-af7ae5.woff2   75.4 KiB                                [emitted]
 fontawesome-webfont-fee66e.woff   95.7 KiB                                [emitted]
  fontawesome-webfont-674f50.eot    162 KiB                                [emitted]
                        login.js   30.5 KiB                         login  [emitted]  login
                      rep_log.js    612 KiB                       rep_log  [emitted]  rep_log
 vendors~layout~login~rep_log.js    771 KiB  vendors~layout~login~rep_log  [emitted]  vendors~layout~login~rep_log
       vendors~layout~rep_log.js    178 KiB        vendors~layout~rep_log  [emitted]  vendors~layout~rep_log
             static/dumbbell.png   6.66 KiB                                [emitted]
Entrypoint rep_log = vendors~layout~login~rep_log.js vendors~layout~rep_log.js rep_log.js
Entrypoint login = vendors~layout~login~rep_log.js login.js
Entrypoint layout = vendors~layout~login~rep_log.js vendors~layout~rep_log.js layout.js
[./assets/css/login.css] 1.1 KiB {login} [built]
[./assets/css/main.scss] 1.43 KiB {layout} [built]
[./assets/images/dumbbell-mini.png] 70 bytes {layout} [built]
[./assets/js/layout.js] 512 bytes {layout} [built]
[./assets/js/login.js] 977 bytes {login} [built]
[./assets/js/rep_log.js] 702 bytes {rep_log} [built]
[./node_modules/css-loader/index.js??ref--5-1!./assets/css/login.css] ./node_modules/css-loader??ref--5-1!./assets/css/login.css 4.68 KiB {login} [built]
[./node_modules/css-loader/index.js??ref--6-1!./node_modules/resolve-url-loader/index.js??ref--6-2!./node_modules/sass-loader/lib/loader.js??ref--6-3!./assets/css/main.scss] ./node_modules/css-loader??ref--6-1!./node_modules/resolve-url-loader??ref--6-2!./node_modules/sass-loader/lib/loader.js??ref--6-3!./assets/css/main.scss 501 KiB {layout} [built]
[./node_modules/webpack/buildin/global.js] (webpack)/buildin/global.js 509 bytes {vendors~layout~rep_log} [built]
    + 364 hidden modules
$ 

The application fails, though with
<blockquote>Uncaught ReferenceError: $ is not defined at lift:218</blockquote>

Actually, the app fails in other ways as well. It appears that none of the CSS is delivered to the browser.
In fact, there are no style CSS link tags in the head.

As far as I can tell, none of the common js files is ever references in the browser.
Looking at the network tab in Chrome only shows the FOS router stuff and the app-specific JS files.

I have spent hours trying to get this to work.

Advice would be most appreciated.

Thanks

Hey David P.!

Unfortunately, I haven't yet worked with Webpack 4 - it's on my "short list" to look at soon (so we can update Webpack Encore), but it hasn't happened yet :/. From my initial reading it seems like the common chunking thing only happens (out of the box) for async chunks - the stuff we cover in the "Code Splitting" chapter. By setting the config to "all" like you did, you ARE activating it for all chunks... but apparently this will require you to add different script tags to your page - Sokra mentions it just a *tiny* bit in the first few sentences: https://gist.github.com/sok.... It appears that the chunking is more automatic, and so the exact script tags you need to have in your HTML source will vary and you need to build the script tags dynamically. That's no small feat.

Again, I need to look into it more. I believe there is a way to control these filenames - check out this guide: https://gist.github.com/gri... - search for "Let's just try to add the new config for the CommonsChunkPlugin replacement and see what happens". Again, I don't have the answers yet, just trying to give the best direction I can at this time.

Let me know what you find out - would love to hear! Cheers!

weaverryan,

Thanks for the response.

I saw @gricard's post over the weekend and didn't really get anything out of it at the time.
Going back today, I reread it <i>and</i> all of the comments.

Using his optimization configuration:

  optimization: {
    splitChunks: {
      cacheGroups: {
        commons: {
          test:   /[\\/]node_modules[\\/]/,
          name:   'vendor',
          chunks: 'all'
        }
      }
    }
  },```


<b>and</b> placing an additional script tag in the index.html.twig template before the buiild/rep_log.js tag, (as mentioned in the comments), seems to have done the trick.

&lt;script src="{{ asset('build/vendor.js') }}">&lt;/script>
&lt;script src="{{ asset('build/rep_log.js') }}">&lt;/script>

Thanks

Hey David P.!

This is GREAT. Nice work, and thank you for sharing! This indeed seems like the "equivalent" for setting up the CommonsChunkPlugin (when you want all of node_modules to be included in it). The next question will be to see if we can make that vendor.js file act like we do in the NEXT chapter: where we make the commons chunk layout.js, and simply prevent anything in layout.js from being in other files (instead of packaging everything in node_modules). It's also possible, considering how much work they've done with the chunk stuff in v4, that thinking about the common chunk in this way is no longer the *best* way. ALL things I need to research soon :).

Again, thanks for sharing - it's a treat for me when I get to learn from the comments :).

Cheers!

@waeverryan,

So here is something simple that you could add to the existing course at the point where we install webpack:

yarn add webpack@3 webpack-cli --dev```


You could add it to the comments and add one of those nice little banners that you use in the video itself.

As I'm sure you're aware, the @3 will cause yarn to install V3. That should remove any hassles for your students until you're ready to release versions for V4.

Just a thought.

Thanks!
Dave
--

Hey David,

Thanks for mentioning it! Yes, exactly what we're going to do. Actually, note about "webpack@3" is already added to this chapter: https://knpuniversity.com/s... . More Webpack4-related notes will be added later. Thanks for your help on it!

Cheers!

Ryan,

Since I want to finish this course and proceed to the Webpack/Encore course, should I uninstall webpack 4 and install webpack 3?
Or, is there a reasonable way to have both of them installed?

Thanks.

Hey David P.!

Great question. At the beginning of the Encore course, we actually *totally* uninstall Webpack before we install Encore (because Encore installs Webpack v3 for you). So yea, basically you'll continue with Webpack V3. But don't worry, you've already tackled (for better or worse) the BIG difference between Webpack v3 and v4 - the common chunk stuff.

Hopefully, not too long from now, we'll upgrade Encore from Webpack v3 to v4. Most likely, as an Encore user, you won't notice much difference, except that your builds will (supposedly) be faster :).

Cheers!