Requirements free version of Yii 2

[hiqsol]

I want to create console only yii2 based application.
And I don't want all those bower assets and other dependencies to be installed.

Don't you mind if I create (and maintain on Packagist) requirements free version of yii2 core code?
It's going to be exact copy of yiisoft/yii2-framework with only composer.json changed.
I've already tried: https://github.com/sol-hiqdev/bare-yii2
It works fine for me and could be useful for others.

Do you plan to split your framework to smaller parts for similar purposes?

[cebe]

we have a similar discussion already, could not find the issue so I will keep this open.
we will consider it for version 2.1.

[hiqsol]

Nice to hear it.
Hope you are about to cut core part out of the whole framework. And it seems to be a very good quality for the core to have no dependencies.

[klimov-paul]

See #10557 (comment)

I suppose this issue does not actually require stripping yii\web\* classes. Moving bower/asset depent widgets would be just enough here.

[klimov-paul]

Current yii2 repo should be split into several ones.
Note, that we should keep a balance regardless future amount of repositories.
I suppose only the code, which has external dependency like jquery should be put into a separated repo.

While using small codebase and many packages may look flexibile it has a drawbacks:

1. It is hard to navigate the code, which is split into several packages

2. Yii architecture is relatively simple and thus sometimes has cross references. For example \yii\db\Connection::$schemaCache existance makes a dependency to yii\caching\* classes, while there is a yii\caching\DbCache, which depends on \yii\db\Connection.

3. Fetching many packages from composer may produce installation performance degradation: the most expensive part of composer instalation is a resolving of the dependency tree, comparing requirements from different packages. The more packages are involved - the more time will be needed.

4. Composer generates an autoload by PSR for each package, remembering its root path. The more packages are installed - the more paths to remember and process. This may slow down the class autoloading.

Of course there should be some balance to be maintained here.

I can see no reason for exracting such packages like web, console or caching.
Except those classes, which have external dependencies, I suppose only yii\rest\* should be separated.

[klimov-paul]

I propose introduction of following new repositories:

1. yii2-jquery
   See Jquery dependency #9525 .
   Root package (yii2) should provide base implementations for yii\web\View, yii\widgets\ActiveForm and yii\grid\GridView, which should be independent of JQuery. While there should be a separated package, which provides View, ActiveForm, GridView and related classes with jQuery support.
   This package should be depended on jquery asset package, while yii2 stripped from such dependency.

2. yii2-pjax
yii\widgets\Pjax should be separated into a separated repo, which will be depended on yii2-jquery and PJax asset package.

3. yii2-maskedinput
yii\widgets\MaskedInput should be separated in the same way as Pjax.

4. yii2-rest
   REST implementation is worth to be extracted to the separated repo.
   Current yii\rest\* should be sugnificantly improved for the better REST support, which is demanded by modern applications.

We should also consider how to deal (if we will actuall) with following dependencies:

• ezyang/htmlpurifier - in general it can be not need for the particular application, however it is bound to Formatter. I am unsure what to do about this package.
• cebe/markdown - It is used at console controller. It seems it should be made optional - but it is hard to say
• bower-asset/punycode - unsure where it is used and thus, where it should be placed.

[klimov-paul]

New repositories may be created even now without waiting for yii2 2.1 version.

We can use Yii::$classMap to override usage of the old classes with the new ones from the particular package.

If we create new repositories beforehand, developers may participate in 2.1 development inside those smaller repos (very crucial for REST, for example) and, perhaps, even use them in thier project, while we will have an ability to reduce amount of issues at yii2 repo bug tracking list.

[hiqsol]

What do you (yii2 team) think about putting sources into src directory?

[samdark]

Agree with @klimov-paul package suggestions 1—4.

ezyang/htmlpurifier is required for sanitizing HTML which is part of most web apps. I don't think it should be separated.

cebe/markdown. Not sure about it. @cebe ?

bower-asset/punycode is used in clientside URL validation. Could be extracted to the same package providing clientside validation.

@hiqsol what's the benefit?

[hiqsol]

@samdark it is commonly (and very widely) used to separate source files from auxiliary files.
Benefit is clarity. Clean root and src dirs.

[klimov-paul]

What do you (yii2 team) think about putting sources into src directory?

It makes no sense. Actually back at alpha state there was an src directory. It was dropped in favor to new PSR autoload standard - PSR-4.

ezyang/htmlpurifier is required for sanitizing HTML which is part of most web apps. I don't think it should be separated.

That is true of course. However, there are application, which do not allow HTML code input and do not show any user-made content without Html::encode() satitization.
For the applications, which provide only REST interface with JSON output - purifying HTML also make no sense: there is no HTML page ever generated, while for JSON there is no need to sanitize HTML if any.

My opinion: ezyang/htmlpurifier should be optional. Formatter may throw an exception is this library is not available.

[dynasource]

My opinion: ezyang/htmlpurifier should be optional

agree. It should be slimmed down to a minimum. Developer should get maximum flexibility.

[klimov-paul]

What do you (yii2 team) think about putting sources into src directory?

Although I may make sense. Originally both framework and extensions like yii2-bootstrap were under the same repo. In time extensions were moved to separated repos. This produce a legacy name for the folder containg the core - framework.
Indeed, it is better to rename it to src for better reading. But this is a different issue.

[samdark]

My opinion: ezyang/htmlpurifier should be optional.

Makes sense. It should be included into default templates though.

[samdark]

Moved masked input into https://github.com/yiisoft/yii2-maskedinput.

[schmunk42]

I've said it in other places, but first and foremost all asset bundles need to be moved out of the core, since those are generating the most friction and require an additional plugin during installation.

If you get a black text on white background saying "Hello Yii 2.1!" we can re-add the asset layer on top.

[schmunk42]

So here's my approach for moving assets out of the core...

Goal: Running Yii 2.1 application without asset-manager, inlcuding code-generation via Gii WebUI.

I had to fork the core, gii and bootstrap for removing all bower-asset dependencies. After that I was able to install Yii 2.1 without the composer-asset-plugin (cap).

For still getting the required assets, I installed foxy in my project and added the previously removed bower-assets to a packages.json file next to composer.json (this should be moved to extension repos).

On a composer update foxy will trigger yarn or npm to install the packages from packages.json - this can also be done manually.

Luckily, to use the exisiting asset-bundles, you can add an alias to your application: @bower => /app/pkg/node_modules, which maps the paths the new location. This will not work for all packages, but makes the transition more easy in early development. Most asset bundles should be updateable by just changing the source path.

All this together (#14832, yiisoft/yii2-gii#301, yiisoft/yii2-bootstrap#212) leads to the above goal.

You can try out an example here: https://github.com/schmunk42/foxy-roxy-rabbit

---

There needs to be more work done (moving code into repos, etc...), but before changing too much, I wanted to hear some feedback, if this could be the asset approach for 2.1.

The only downside is that you need yarn or npm installed, but it solves most of the issues people had with cap.

When not installing foxy and the gii package, you can run ie. a CLI or REST application without any asset packages and only a handful of dependencies.

[klimov-paul]

I can not see how usage of the 'Foxy' solves this issue. It is an alternative approach for asset installation.
yii\web\ActiveForm or yii\grid\GridView are still unable to function without JQuery.

For me "requirements free version" means package, which provides its full functionality without extra libaries to be installed. It may lack some minor features providing 'suggest' section in composer.json, but it can not hold entire package of widgets, which relies on JQuery package.

Usage of separated packages for assets brings back the issue about version dependecy tracking and possible version conflicts.
I do not like Yii packages to be tired to ANY asset retrieval solution any more, as it always may happen some developer need to use another tool for it.

To solve the issue all external asset depended code (JQuery depended) should be moved to separated package. After then we can consider in which way this package should deal with assets.

Since for Yii is tired to JQuery library, which is relatively simple, I would suggest that by default yii2-jquery will provide JQueryAsset with source loaded from public CDN.
AssetManager allows overriding of any asset, changing its source from external URL to local file if needed. Thus developer will choose in which way he wish to get jquery.js and configure JQueryAsset accordingly.
Using public CDN allows potential yii2-jquery package to function 'out-of-box' without extra effots in 90% cases, while using AssetManager developer can provide any source for JQuery to covering absolutely all cases.

Moving to CDN can not be done at 2.x, but can be at 2.1.

[sergeymakinen]

@klimov-paul 👍

Yeah, moving to CDNs should be okay.

Dropping composer asset managers can make widget developer's life harder but it will happen - sooner or later. I'd prefer it to happen in 2.1.

[schmunk42]

yii\web\ActiveForm or yii\grid\GridView are still unable to function without JQuery.

To solve the issue all external asset depended code (JQuery depended) should be moved to separated package. After then we can consider in which way this package should deal with assets.

Yes, both should be moved out of the core.

Using public CDN allows potential yii2-jquery package to function 'out-of-box' without extra effots in 90% cases, while using AssetManager developer can provide any source for JQuery to covering absolutely all cases.

Moving to CDN can not be done at 2.x, but can be at 2.1.

Moving to CDN by default is an absolut no-go, IMHO, please see this blog posting for a description of security issues.

[klimov-paul]

Repository has been split. Following new packages extracted:

• yiisoft/yii2-jquery
• yiisoft/yii2-captcha
• yiisoft/yii2-rest
• yiisoft/yii2-mssql
• yiisoft/yii2-oracle

Dependency of the assets is no longer affects main repo, it affects only extensions like "yiisoft/yii2-jquery" or "yiisoft/yii2-bootstrap".

Now "yiisoft/yii2" depends only on PSR repos and "cebe/markdown". I consider this list of requirements can not be shorten (at least it does not make sense).