Bower VS Yii2

Bower is a package manager specifically designed for front-end web development. It can be used to manage JavaScript, CSS, and HTML packages and dependencies. It was developed by Twitter and is known for its simplicity and ease of use. However, it is worth noting that Bower is no longer actively maintained, and developers are encouraged to use other package managers like Yarn or PNPM instead.

Bower dependency directory (https://bower.io/)

What we see, a decade ago, are that many of the "popular" libraries, frameworks, and methods, not surprisingly, have gone by the wayside, a lot that have remained in current code as difficult-to-removemodernize legacy cruft (Bower, Gulp, Grunt, Backbone, Angular 1, ...), and then we have the small minority that are still here. Some that remain have had their utility lessened/questioned by platform and language improvements (jQuery, lodash, ...), but very, very few exist that are the same now as they were then. Another fun historical reference: issue #118 of "JavaScript Weekly" (February 22, 2013) includes a first link out to asm.js.

In this way, all the packages that we add in the require section of composer.json, will be installed in the ./node_modulesdirectory, and their download will be managed by asset-packagist, to see the available packages, you can search for both bower and npm packages.

# Logs logs *.log npm-debug.log* yarn-debug.log* yarn-error.log* lerna-debug.log* .pnpm-debug.log* # Diagnostic reports (https://nodejs.org/api/report.html) report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json # Runtime data pids *.pid *.seed *.pid.lock # Directory for instrumented libs generated by jscoverage/JSCover lib-cov # Coverage directory used by tools like istanbul coverage *.lcov # nyc test coverage .nyc_output # Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files) .grunt # Bower dependency directory (https://bower.io/) bower_components # node-waf configuration .lock-wscript # Compiled binary addons (https://nodejs.org/api/addons.html) build/Release # Dependency directories node_modules/ jspm_packages/ # Snowpack dependency directory (https://snowpack.dev/) web_modules/ # TypeScript cache *.tsbuildinfo # Optional npm cache directory .npm # Optional eslint cache .eslintcache # Optional stylelint cache .stylelintcache # Microbundle cache .rpt2_cache/ .rts2_cache_cjs/ .rts2_cache_es/ .rts2_cache_umd/ # Optional REPL history .node_repl_history # Output of 'npm pack' *.tgz # Yarn Integrity file .yarn-integrity # dotenv environment variable files .env .env.development.local .env.test.local .env.production.local .env.local # parcel-bundler cache (https://parceljs.org/) .cache .parcel-cache # Next.js build output .next out # Nuxt.js build / generate output .nuxt dist # Gatsby files .cache/ # Comment in the public line in if your project uses Gatsby and not Next.js # https://nextjs.org/blog/next-9-1#public-directory-support # public # vuepress build output .vuepress/dist # vuepress v2.x temp and cache directory .temp .cache # Docusaurus cache and generated files .docusaurus # Serverless directories .serverless/ # FuseBox cache .fusebox/ # DynamoDB Local files .dynamodb/ # TernJS port file .tern-port # Stores VSCode versions used for testing VSCode extensions .vscode-test # yarn v2 .yarn/cache .yarn/unplugged .yarn/build-state.yml .yarn/install-state.gz .pnp.*

Like this?

# Bower dependency directory (https://bower.io/) bower_components

diff --git a/.gitignore b/.gitignore index d451ff1..0b799e4 100644 --- a/.gitignore +++ b/.gitignore @@ -1,5 +1,122 @@ -node_modules -.DS_Store +# Logs +logs +*.log +npm-debug.log* +yarn-debug.log* +yarn-error.log* +lerna-debug.log* +.pnpm-debug.log* + +# Diagnostic reports (https://nodejs.org/api/report.html) +report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json + +# Runtime data +pids +*.pid +*.seed +*.pid.lock + +# Directory for instrumented libs generated by jscoverage/JSCover +lib-cov + +# Coverage directory used by tools like istanbul +coverage +*.lcov + +# nyc test coverage +.nyc_output + +# Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files) +.grunt + +# Bower dependency directory (https://bower.io/) +bower_components + +# node-waf configuration +.lock-wscript + +# Compiled binary addons (https://nodejs.org/api/addons.html) +build/Release + +# Dependency directories +node_modules/ +jspm_packages/ + +# Snowpack dependency directory (https://snowpack.dev/) +web_modules/ + +# TypeScript cache +*.tsbuildinfo + +# Optional npm cache directory +.npm + +# Optional eslint cache +.eslintcache + +# Microbundle cache +.rpt2_cache/ +.rts2_cache_cjs/ +.rts2_cache_es/ +.rts2_cache_umd/ + +# Optional REPL history +.node_repl_history + +# Output of 'npm pack' +*.tgz + +# Yarn Integrity file +.yarn-integrity + +# dotenv environment variables file +.env +.env.test +.env.production + +# parcel-bundler cache (https://parceljs.org/) +.cache +.parcel-cache + +# Next.js build output +.next +out + +# Nuxt.js build / generate output +.nuxt dist + +# Gatsby files +.cache/ +# Comment in the public line in if your project uses Gatsby and not Next.js +# https://nextjs.org/blog/next-9-1#public-directory-support +# public + +# vuepress build output +.vuepress/dist + +# Serverless directories +.serverless/ + +# FuseBox cache +.fusebox/ + +# DynamoDB Local files +.dynamodb/ + +# TernJS port file +.tern-port + +# Stores VSCode versions used for testing VSCode extensions +.vscode-test + +# yarn v2 +.yarn/cache +.yarn/unplugged +.yarn/build-state.yml +.yarn/install-state.gz +.pnp.* + +# Project dist-ssr *.local

# Logs logs *.log npm-debug.log* yarn-debug.log* yarn-error.log* # Runtime data pids *.pid *.seed *.pid.lock # Directory for instrumented libs generated by jscoverage/JSCover lib-cov # Coverage directory used by tools like istanbul coverage # nyc test coverage .nyc_output # Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files) .grunt # Bower dependency directory (https://bower.io/) bower_components # node-waf configuration .lock-wscript # Compiled binary addons (http://nodejs.org/api/addons.html) build/Release # Dependency directories node_modules/ jspm_packages/ # Typescript v1 declaration files typings/ # Optional npm cache directory .npm # Optional eslint cache .eslintcache # Optional REPL history .node_repl_history # Output of 'npm pack' *.tgz # dotenv environment variable files .env* # gatsby files .cache/ # Mac files .DS_Store # Yarn yarn-error.log .pnp/ .pnp.js # Yarn Integrity file .yarn-integrity

Yii is one of the oldest PHP frameworks, acronym as Yes It Is! It has 14.2k stars and 7k forks on GitHub. It is a fast, secure, and flexible PHP framework for web development, especially for building MVC architecture websites. It is an Object-Oriented PHP framework that requires knowledge of inheritance, polymorphism, etc.

In Yii Framework we have a middleware that will allow us to access our applications without the need to point the web server to the public directory of each template, so we will use the middleware SubFolder::class.

asset-packagist: This is the traditional Yii2 way, here we will add the following to our composer.json.

It is often preferable to manage Yii Assets programmatically. For example, when you use the widget in a page, it will automatically include the required css and javascript files, instead of asking you to manually find these files and include them. And when you upgrade the widget to a new version, it will automatically use the new version of the Yii Assets. In this tutorial, we will describe the powerful Yii Assets management capability provided in Yii Framework .

As we can see in the example above, we have defined the configuration of our packages in files .php (it doesn’t matter if they are YiiFramework packages or not), this allows us to define the configuration of each component in a very simple way to understand.

Now if we want to create an extension, under the code standard used in the Yii Framework v.3 packages, we can use yiisoft/template, provides us the tools necessary for our code to comply with good coding standards they are:

Now we understand how to do any configuration of any YiiFramework package or external, it is not necessary to have a single long and complex configuration file, we can organize it according to the group of configurations and Yii config will do the work for you, as well as the container it applies the definitions for you, with the automatic wiring facility in controllers, which makes it easy to access any container dependency without the need to use static access to it, or depend on the container itself.