Download the PHP package bit3/packer without Composer

On this page you can find all versions of the php package bit3/packer. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package packer

CSS/JS distribution packer

Add a package.yml to your repository and run the pack command.

Configuration

There are 3 configuration files.

The default.yml contains the default configuration.

The package.yml contains the package configuration, for your project. This one should be added to your repository.

The package.local.yml contains system / environment specific configuration (like paths to binaries). This one should not be added to your repository.

They will be loaded in this order and merged into each other. That means in general you package.yml contains the package information, while the package.local.yml contains paths to the binaries on your system.

Convenience: If you want to provide a package.local.yml that works for your team, for example all use the same system environment, put a package.local.yml.dist with system environment specific settings into you repository. You should not overcharge the package.yml with system environment specific settings!

Watching modifications

A lot compilers like sass/compass have a "watch" feature. But when using chains of compilers and minifiers, this is not easy to automating. Use the --watch (-w) flag will cause the packer to watch for modifications on the packages.

If you using importing (like the sass @import rule) or embedding (like the cssembed filter), you may want to specify which files must be watched?! Simply add a watch block into your package.yml, directly after the files block and specify the files or directories to watch.

Deployment

Using the "watch" feature is nice for local development, but what if you must compile local and push to a remote host? This may necessary when your website is placed on a shared host, without shell/compiler support.

Using deployment is realy easy, first you need to define your deployment commands:

And use the --deploy option to your command: pack --deploy

After each package, the deployment will be executed. The placeholder %file% is replaced with the pathname of the package, %package% with the name of the package and %deploy% with the deployment target (which is default by default).

Output example

Deployment targets

Having one deployment target is nice for simple setups, but what if you need to deploy to multiple places depending on what you currently work on? One possible usage scenario is a preview and production deployment.

When you add the deploy section, all commands will be added to the default deployment targets. To define multiple deployment targets, group the commands inside of the deploy section.

Now you have two deployment targets which can be used particular by pack --deploy preview and pack --deploy production, or together with a single pack --deploy preview --deploy production.

Hint There is simply no difference between

and

Hint It is also possible to mix grouped and non-grouped commands:

which is exactly the same as:

Warning If you want to deploy specific packages (pack dist/only_this_package.css) and deploy these to the default deployment target (pack --deploy), the package name may be assumed as deployment target, if you just use pack --deploy dist/only_this_package.css. Just add default after --deploy: pack --deploy default dist/only_this_package.css or simply switch the parameters: pack dist/only_this_package.css --deploy.

package.yml reference

All versions of packer with dependencies

PHP Build Version
Package Version
Requires php Version >=5.4
symfony/console Version 2.4.*
symfony/process Version 2.4.*
symfony/yaml Version 2.4.*
kriswallsmith/assetic Version ~1.1
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package bit3/packer contains the following files

Loading the files please wait ....