Support Webpack Native

Yii 3.0 Design discussions
1

Good morning excellent all the new changes of Yii 3.0 have undoubtedly taken a big step, it would be a great achievement that we had an official extension for the management of webpack and could separate the assets of yii\web as an independent extension so the frame would be even more flexible and powerful, since we could use the current topics that all use webpack, I think that extension should be official it will be more work but if they take the decision to do so they can guide us to build it in the best possible way.

3 Likes
2

Symfony have https://symfony.com/doc/current/frontend.html#webpack-encore
Laravel have https://laravel.com/docs/5.8/mix

Not sure if we should come up with yet another wrapper, or just use an existing one.

3

It would be good to have our own extension taking advantage of all the benefits of the Yii v 3.0 framework and not depend on such an important third party function.

If we are going to send to use extensions made in Laravel, many will learn Laravel at once.

4

I agree. Having our own extension would allow optimizations specific to Yii.

5

There was a whole thing here, where I suggested they take advantage of Webpack.

Was met with people that apparently hate it. ¯_(ツ)_/¯

6

it’s not about hating the web package, but without having support for webpack, Yii v. 3.0 will not have many themes, since the best ones that exist are based on the webpack package.

7

Yeah, but if they don’t like it, they won’t do it. You can see I argued for Webpack support, but it was met with objections.

8

Well we hope to see the response from @samdark @machour @CeBe @rob006 @schmunk, @fabriziocaldarelli, @hiqsol maybe we’re seeing it from the wrong side, but the good themes are all in webpack, and converting one with gulp, yarn is already a great effort, to integrate them to Yii, if we could have the traditional approach of the assets, more webpack support we could basically incorporate them without any problem.

Of course it’s just my opinion.

1 Like
9

I went through the whole thread you’ve linked, and I’m definitely for modernizing Yii’s approach when it comes to javascript, and assets in general!

I like your idea of rewriting our JS using ES6, and provide both these files (src) and a bundled version (dist) for developers to work with. It makes a lot of sense, and shouldn’t be a blocker for people who do not care.

I personally would favor doing that using Typescript, to be also able to export interfaces & typings.

We could internally use rollup, webpack or another bundler, this would be (almost give or take 1 or 2 kb) totally transparent for the end user.

I’ll happily discuss the idea with you, and make it happen if it’s fine with everyone :raised_hands:

@vanhelvzla raises an another concern however, which is, how to improve the developer experience, working with her/his own javascript.

In that I agree, something must be done, and the fact that Yii 3 is trying to be js-framework agnostic, doesn’t mean that it shouldn’t provide the user with the best DX possible & modern best practices.

Here, and after giving it some thoughts, I think we could come up with an official extension which would:

  • Use webpack (or another bundler, that’s up for debate) with some well thoughts defaults
  • Leverage the manifest.json file produced by the bundler in our PHP AssetBundles
  • Make it easy for me to split my js/css bundles (may work well with how Yii combines assets )
  • Provide me with browsersync for live browser updates whether I’m working on my sass or php
  • More goodies?

There are a few more topics I’d like to discuss as well, like:

  • SPA developments with Yii. What can we improve with the API side (see the validation concern for example here: Assets, asset publishing)
  • Providing enhanced support for VueJs. Maybe a template, some widgets, validation, …

cc @toMeloos which have been gaining some momentum on this lately

1 Like
10

Before thinking about a wrapper we should start with writing documentation how to use native webpack with Yii 3.

As said many times before (in other places), in the JS world, a framework can become quite unpopular in a rather short span of time, so we should not rely on a specific JS framework, but design Yii 3 to be flexible enough to use different ones.

Problem: grunt, solution: gulp, problem: gulp.
https://medium.com/javascript-non-grata/down-the-javascript-hole-f45417ce7d1f :speak_no_evil:

…solution: webpack, problem: webpack. :joy:

eg. we recently had to use config.optimization.delete('splitChunks') in our config, actually we have no idea why and we also did not find a proper explanation. https://forum.vuejs.org/t/error-when-loading-vue-on-a-webpage-that-uses-webpack-3/48955

1 Like
11

Before thinking about a wrapper we should start with writing documentation how to use native webpack with Yii 3.

You mean an official tutorial to install & configure webpack to work nicely with Yii?
I’m all for it, and I would also love to see the same thing for gulp.

This actually would be a good first step towards coming up with our wrapper.

a framework can become quite unpopular in a rather short span of time, so we should not rely on a specific JS framework, but design Yii 3 to be flexible enough to use different ones.

Here we’re not talking about webpack anymore, but jQuery/Vue/React.

I totally agree with you: out of the box, Yii shouldn’t make any assumptions about what you’ll be using as JS framework (or bundler too).

Js frameworks have been indeed known to come & go, but some of them are here now, widely used and (imho) here to stay, like Vue or React.

It does make sense to me to provide enhanced support for those if we have enough resources. Vue ability to be integrated like jQuery (widgets) on a Yii outputted page makes it a really good candidate.

eg. we recently had to use config.optimization.delete('splitChunks') in our config

:rofl: at the comic strip! Yes, webpack can be a wild beast some times, and I’ve personally always end up using something wrapped around it that dumbs it down to my level of patience.

Thing is, we should avoid at any costs having to deal with webpack support issues at Yii, so our wrapper should just stay that, a wrapper, adding some handy shortcuts to quickly get you started.
All of webpack’s config should be totally controllable by the user, if he wants to dive into that.

12

It is correct when I propose the support, I am thinking of an extension to manage the assets independently of the Yii framework, and that everyone can choose what to use, and the truth if we look for how many topics are available for Yii 2 we see that they all work with AdminLTE , which is not commercial, to the end when we use the framework for our projects and we have a client, and he asks us to use the Nebular theme, we must move on to find another solution that suits what the client asks, but if in some way we can handle that with Yii 3.0 will be a breakthrough of the frame, it’s like when you’re going to sell a cake if it does not look good, people will be afraid to try it.

“No software is free of problems, it will always have one, but we do not stop using it”.

It’s only my 2 cents.

1 Like
13

Disclaimer: I’m not very familiar with Webpack.

This useful discussion could probably benefit from distinguishing between two use-cases:

  1. A “traditional” application that has a PHP based, server-side rendered, front-end (with yii3 it will be using yii-web), probably enriched with JavaScript script assets (jQuery, Vue.JS, etc.). I’m guessing Webpack might be very useful in modernizing Yii3’s way of handling assets in this scenario. By all means explore the opportunities!

  2. A “modern” application with a PHP based back-end providing an API interface (REST, GraphQL) coupled with a JavaScript framework front-end (Angular/React/Vue/??? based) that consumes the API. Either SSR with Node.JS or a SPA. These are two separate code bases so Webpack probably isn’t needed here.

I’m confident that everyone agrees with @schmunk’s assertion that Yii should be as JS framework independent as possible given the constant change still happening in the JS landscape. In the “modern” application scenario Yii is totally JS agnostic, given that interaction happens through standardized API’s. However there are loads of traditional applications that are miles away from a full rewrite with API’s and a JS framework, and providing these with a gradual migration path would make Yii more appealing. Like @machour said, jQuery isn’t going anywhere any time soon and Vue.JS has the huge selling point of being able to run both as a simple snipet and a full-blown SPA framework, providing a gradual migration path. I’m sure this is why the folks at Laravel expressed their preference for Vue.JS and integrated it tightly in their equivalent of yii-web.

3 Likes
14

I think it would be the right approach, totally in agreement.

15

:speak_no_evil: @pika/web brings that nostalgic, 2014 simplicity to 2019 web development:

3 Likes
16

The important thing is not webpack but we have a modern tool that allows us to work in the frontend

17

It is a new tool every 6-8 months…

18

A yii2 extension to support webpack assets: https://github.com/pgaultier/yii2-webpack

19

I personally would favor doing that using Typescript, to be also able to export interfaces & typings.

It could be done in TypeScript for development purposes and then compiled to ES6 and pre-bundled for releases — I’ve seen this done, but I don’t remember where. That the TS could also be available in the release package as well. That way if people want to use TS they can, or they can use plain JS and bundle it independently, or use the pre-bundled. I wouldn’t use TS, I know it has a number of advantages, but atm it’s just not something that I’m personally using, but I don’t see a reason not to have it.

I think that an argument could be made for that is why not then have a package for Angular, Vue, and React if you’re going to support TS. To that I would say that the difference is TS isn’t a framework, but a superset of JavaScript — it’s more akin to it’s own language than a framework, like Groovy to Java. Furthermore, it’s a separation of development and maintenance for the package and what’s released for one’s own project development.

Does Rollup only use CommonJS or does it now support ES6 import and export statements? If it’s the former, I don’t think it should go that route. For Yii, it should stick closer to modern JavaScript. This would make transitioning easier later if and when bundlers are not necessary — kind of like what Pika talks about doing. This way said tooling can be used, but doesn’t have to be going forward in the future.

1 Like
20

New tooling is always coming out, but Webpack has major support from big players. That’s like saying you shouldn’t get a new phone, because in 9 – 10 months a new version of the phone will come out. Or that you don’t want to release v1 of some project you’re working on because you want to add new features (1.0-itis).

Or, something a little closer to home. Why Yii, there’s always going to be a new framework, or even a little more generically. Why PHP, there’s new languages. The key is to pick something that aligns with what you’re attempting to accomplish. As I mentioned above, going with ES6 and Webpack, or any other tooling that supports ES6 import and export, makes it more future compatible for if and when bundlers aren’t necessary. If you go with TS you can have three different options, TS for development/maintenance and people that want to build it themselves, compiled ES6 for independent bundling, and pre-bundled for direct browser usage.

1 Like