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
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.
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.
I agree. Having our own extension would allow optimizations specific to Yii.
There was a whole thing here, where I suggested they take advantage of Webpack.
Was met with people that apparently hate it. ĀÆ_(ć)_/ĀÆ
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.
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.
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
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 
@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.jsonfile 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
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 
ā¦solution: webpack, problem: webpack. 
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
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
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.
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
Disclaimer: Iām not very familiar with Webpack.
This useful discussion could probably benefit from distinguishing between two use-cases:
-
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! -
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
I think it would be the right approach, totally in agreement.
@pika/web brings that nostalgic, 2014 simplicity to 2019 web development:
3 Likes
The important thing is not webpack but we have a modern tool that allows us to work in the frontend
It is a new tool every 6-8 monthsā¦
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
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