Hhvm Autoload Versions Save

Autoload classes, functions, enums, constants, and typedefs on HHVM

v2.0.7

4 years ago

v2.0.6

5 years ago

This release removes usage of static locals, which will be unsupported in 4.1

v2.0.5

5 years ago

v2.0.4

5 years ago

This release fixes compatibility with nightly builds, by replacing <?hh with <?hh // partial

This will be required in 4.1

v1.8

5 years ago

This release is intended for users of HHVM 3.30; users of HHVM 4 should use hhvm-autoload v2.x. This release:

  • fixes relative path support
  • modifies the composer plugin to execute the autoloader in a sub-process; this provides a cleaner upgrade path to 4.0, as with 4.0, PHP must be used to execute Composer - and PHP can not load the current plugin.

v2.0.3

5 years ago
  • hhvm-autoload 2 requires the HSL, but did not explicitly depend on it
  • 2.0.0-2.0.2 look for vendor/hhvm/hsl/, but for the HSL itself, this directory does not exist.

v2.0.2

5 years ago

Composer now needs to execute the autoloader in a subprocess; this worked, but was not updated for the move to .hack files.

v2.0.1

5 years ago
  • clean test run
  • fix relative paths in generated .hack files

v2.0

5 years ago

In this release:

  • HHVM 4.0 is supported and required
  • .hack files are supported
  • The composer plugin will now shell out to hhvm-autoload, to allow executing Composer with PHP instead of HHVM
  • vendor/autoload.hack is now generated; the preferred usage is to require() this file, then call Facebook\AutoloadMap\initialize(); hh_autoload.hh and hh_autoload.php are still generated for compatibility, but heavily discouraged.
  • The hh-autoload executable is now a shell script that launches hh-autoload.hack; either execute vendor/bin/hh-autoload without specifying an interpreter, or hhvm vendor/bin/hh-autoload.hack
  • Writer:::writeToFile() will now write just to the file specified. Writer::writeToDirectory() should be used to also generate the backwards-compatibility files.

v1.7

5 years ago

This release:

  • removes the HHI
  • generates <?hh instead of <?php

In theory, this is fully compatible - however I've bumped the minor version as the removal of the HHI does mean that your project will have type errors until the autoload map is generated, if your project reads generated data (e.g. Facebook\AutolaodMap\Generated\is_dev())