-
-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Asset management in Yii 2.1 #7
Comments
JS is crazy, it is growing too fast and libs are getting deprecated/replaced too soon. I think you are right, IMHO 2.1 release is a good opportunity to get rid of as much JS dependencies as possible and maybe figure out a more flexible way to let developer implement what to use using whatever dependency tool he needs. |
It might help to think in terms of what would work well for the demo apps. IMO we want yii2-app-basic to have an easy quick-start but also allow scaling to realistic complex projects. If it would it be acceptable that it has a packages.json in root dir and requires the user to run an npm command then I think we can do it. The npm command runs npm-scripts that run sass, webpack or whatever we want. This means that Yii takes a bit different direction in that it expects the user to take responsibility for managing asset dependencies and processing separately from Yii. Npm and packages.json alone is not the right tooling except for rather simple projects and I think this works well for us. a) It means users have freedom to take asset management it in any direction. And b) it nudges them to take responsibility for this freedom sooner rather than later as their projects grow. |
Btw, to explain myself a bit (or possibly to confuse y'all because I'm going meta:), I have given up hope that DRY is an appropriate goal in the configuration of a Yii project's PHP and non-PHP dependencies. My history in Yii 1.1 and 2.0 led me to conclude that, in the long run, the tooling needed for DRY leads to more, not fewer, maintenance headaches, such as those Tobias diagnosed here and elsewhere. In practice this means that I now prefer to require developers to "manually" maintain the relationship between their PHP and non-PHP worlds. That is to say, they have to keep two configurations in a working alignment. I believe this is an exception to DRY, which "says that every piece of system knowledge should have one authoritative, unambiguous representation." Yii will serve its users well if it gives them a good start on this road and this is better than involving magic that obscures the inevitable problem. |
|
Maybe 2.1 could remove bower library that it's only used in registering assets position. I think each engineer has to know which codes or register position depends on bower's library, so I hope it's an optional way, not required for installing. |
Bower isn't used in registering asset position... would you please elaborate? |
When programmer registered position using POS_READY, the View component will register jQuery asset bundle into page @see https://github.com/yiisoft/yii2/edit/master/framework/web/View.php#L469, but maybe i am wrong, because I didn't view all lines. ^^ |
Yes. That's correct. That has nothing to do with bower though. Ability to register scripts on DOM ready will be moved out of the core in 2.1 or removed altogether. |
from yiisoft/yii-jquery#1 (comment) CC: @klimov-paul
There's no decision at all made about any plugin - the only proposal I made is to remove the JS/CSS-
CDN is a no-go IMHO, I explained that here: yiisoft/yii2#8452 (comment) - Yii should not use this by default.
As said above, there are no-plugins involved or mandatory ones planned. [addon] We need to start somewhere, I'd say |
If asset dependencies are removed from
It may have a drawbacks, but in case CDN is absolutely unacceptable as you say, then no official CDN (like https://code.jquery.com/) would ever exist, but they do. One way or another each asset-dependent package should have an explicit instructions about possible asset setup. I have already added those: They already include the instrutions, which allows to aviod of installation of assets via composer. The final decision on this matter depends on the status of However in case JQuery can not be removed from I do not consider this issue to be a top priority - the top priority is upgrading |
I'm positive that it's possible to remove jQuery dependency from both debug and gii. |
I will believe it when I see it. |
The big downside, if assets are in
Version checking could be handled with foxy, if you want that, but it must not be required for installation. In a nutshell: Install composer packages, install npm packages, in case of an error with npm, revert both. As laid out in the inital posting, I see no way how an installation of npm packages will be maintainable with AP or CAP in the future, since multiple versions of dependent packages can be installed with npm, see for example hiqdev/asset-packagist#69 - that problem did not exist with bower. If we keep |
@schmunk42, if you are sure what to do, then do it: open the pull requests with documentation adjustments, which shows how developer can install assets using 'foxy', using NPM client and so on. Simple removal of the lines from Pull requests like yiisoft/yii2-bootstrap#212 can not be considered as a solution: removing package dependencies without providing information about how it should be handled now is actually a bug creation. |
@klimov-paul I agree that there has to be documentation etc. but I did not want to step too far ahead ;) The work in progress was not continued, because issues like yiisoft/yii2#14832 are totally blocking development, since you can't install the core in 2.1 without CAP or AP. The same goes for gii and debug, since they require bootstrap and assets. And continues with application templates, it can not be done all at once. All proposed changes should be done in 2.1 branches - IMO some smaller breaks here are OK in such an early devleopment stage. I'd also consider it as a bug to require non-mandatory stuff (AP or CAP) otherwise you can not even install. About prios and PRs core
jquery
bootstrap
gii, debug
App Templates
We also need to differentiate the installation of assets for development/testing in the repo - and in an application. |
Here's another idea, although it involves a plugin (but in project scope(!)) and maintenance of two files, I'd like to share it. If you want automatic asset installation without
A package would have to maintain Disclaimer: untested but I am pretty confident that it would work and might be a compromise we all can live with. Let me know if this is an option to check out. |
??? |
Great! I didn't notice, even though it was on 2.1 in the repo for 19 hours already :) btw: You missed the documentation part in the README from my PR to remove the asset plugin, see https://github.com/yiisoft/yii2/pull/14832/files#diff-8db66c46d0073891dfc96775fcf3682c - also the repositories section for AP can be removed. Could you take care of it, I'll close my PR since it's mostly obsolete and can not be updated easily. |
7cf9116fe6eb755b9cfa4c383f42b7ce401df864 |
One more general thing about asset-management in Yii 2.1. We should remove all possiblities to add logic to asset-bundles, like calling |
There could be situations that it could be useful apply some changes. Take specific version of js or css (for debug, eccc..)., isn't it ? |
You mean like using a non-minified version, when |
So do you suggest for development to use a different asset bundle? In this way, I should change also references inside source code, to switch from production asset bundle to development asset bundle. I don't understard this part:
Can you make an example? |
Take this asset-bundle for example https://github.com/beowulfenator/yii2-json-editor/blob/master/src/JsonEditorAsset.php It uses different files when in
Actually the opposite. If you need to bundle an minify, this is your job, not the one of asset-bundles, which might work differently. An asset bundle should only be able to define files and dependencies. Another example is this https://github.com/dmstr/yii2-adminlte-asset/blob/master/web/AdminLteAsset.php If a property is set, include another CSS file. This does not happen during bundling, so you usually get an error, when using the bundled version. |
This could happen also using an asset bundle that defines only files and dependencies; because if you work on a non-minified version and forget to update the minified version, the result is the same.
In that case, the "skin" property is never set out of AdminLteAsset. I don't understand how could be used. Is that a code that could be removed? |
I think this is already solved with foxy and hidev-composer-plugin, and you can configure the option setAlternatives in assetmanager by default comes |
I think at least documentation should be done. |
Done. |
Docs now give foxy as an example. Application template would use it as well. |
This issue is about asset-management in general for Yii 2.1. While there's already a checked box for "Make fxp composer plugin optional. Describe how to use asset packagist instead." on https://github.com/yiisoft/yii2/wiki/Plan-for-next-major-versions#client-side I still think we need to elaborate on this topic.
Current situation with
bower
In the current state the Yii ecosystem mainly uses
bower-asset
s for installing client side scripts (or CSS) packages. This can either be done using https://github.com/fxpio/composer-asset-plugin (cap) or https://github.com/hiqdev/asset-packagist (ap).One of the main issues with this approach is that
bower
is deprecated yiisoft/yii2#14297, and projects start dropping bower support (eg. https://news.ycombinator.com/item?id=10891324, lodash/lodash#2206 (comment), chartjs/Chart.js#3081 {they brought it back, but still...}).While this currently does not affect "near-core" packages, like jquery or bootstrap, there should be a safe migration path to
npm
in planning.Yii 2.1 should also deprecate
bower
usage, while still having the possiblity to use 2.0 extensions with bower via a separate ap-URL, see hiqdev/asset-packagist#67Moving to
npm
While both tools mentioned above (cap, ap) are able to work with
npm
packages, there might (I'd say will) be huge issues, when switching tonpm
packages (ie. hiqdev/asset-packagist#69, hiqdev/asset-packagist#68) One problematic dependency isminimist
- a lib with over 10M downloads ... a week(!). A dependency of over 8000 other projects; details are outlined here - it boils down to flat (composer, bower) vs. tree (npm) installation.That's also one reason why foxy was created. The basic idea is to use native tooling for client side packages (
npm
/yarn
/webpack
- currently), along withpackage.json
files, while still having a minimal connection for dependency resolution between server and client side packages, for ie. widgets or REST API connectors.There are also discussions about smooth transitions for older packages, see fxpio/foxy#8
The main question here is: How will Yii2 core-extensions require assets? (should be best-practice)
Using
npm-asset/package
looks convenient in the first place, but as layed out above, this might fail even in smaller setups - IMHO we currently do not see issues popping up about this, because only few people usenpm-asset
. Another contra is thatcomposer.json
is "polluted" with a package-syntax which does not belong there.[update] Another con of ap is that every not-registered package will throw an error unless manually registered on their website, which can be pretty cumbersome on projects with a lot of dependencies.
A con using foxy +
packages.json
requiresnode
+npm
oryarn
to be installed.[update] There's also a proposal to use a CDN for delivering assets by default, which is not a viable solution IMHO, see yiisoft/yii2#8452 (comment)
Conclusion
The ideal solution would be something where the developers can freely choose which solution they want to use.
Feedback highly appreciated. CC: @yiisoft/core-developers @mikehaertl @tonydspaniard
More related issues/PRs:
The text was updated successfully, but these errors were encountered: