Support HHVM 3.24, require HHVM 3.23+

v1.5.4

Support HHVM 3.24, require HHVM 3.23

Fix upgrade issue

When upgrading plugins, some code may be old, and some may be new, within the same plugins. Remove assertion about caller, and default to dev mode.

Expose dev vs prod mode in generated code

Adds function Facebook\AutoloadMap\Generated\is_dev(): bool

XHP and PSR-0 improvements

• HHClientFallbackHandler now supports XHP
• PSR0 support now correctly handles underscores
• tests/ directory is now compatible with the optional_shape_fields experimental hhconfig option; this directory should not be present in most installations
• documentation improvements

Thanks to @TJ09 and @simonwelsh

Auto-updating autoload maps and custom failure handlers

Package Name

This is now hhvm/hhvm-autoload instead of facebook/hhvm-autoload on Composer/Packagist, for consistency with other 'core' packages such as the Hack Standard Library.

Auto-Updating Autoload Maps

To avoid the need to rebuild the map when changing Hack files, set the new devFailureHandler option to "Facebook\\AutoloadMap\\HHClientFallbackHandler" in your hh_autoload.json; when loading a definition from the map fails, hhvm-autoload will ask hh_client where to find them.

You will still need to manually rebuild if:

• you are changing PHP files (but not when updating/adding/removing PHP dependencies with composer)
• you are changing functions or constants that have the same name as one in the global namespaces
• the environment variables CI, CONTINUOUS_INTEGRATION, or TRAVIS are set; the idea is that test environments should probably be closer to production, and this behavior shouldn't be used on production.

This handler is current opt-in, but is likely to be the default in development environments in a future release.

Custom Failure Handlers

You can extend Facebook\\AutoloadMap\\HHClientFallbackHandler to use it in CI environments, remove caching, etc, or directly extend FailureHandler to add other behavior - for example, logging, or following a convention such as PSR-0 or PSR-4.

Setting the failureHandler option will affect prod and dev, unless the devFailureOption is set.

Other Changes

• removed the dependency on TypeAssert; this was effectively pinning the community to the same major version of TypeAssert as hhvm-autoload uses. In the future, we will be more conservative about adding additional dependencies.
• .hh files are now supported by the PSR0 and PSR4 emulation
• "extraFiles" and "autoloadFilesBehavior": "exec" now use relative paths unless relativeAutoloadRoot is set to false

vendor/bin/hh-autoload will run with type errors, slightly clean up release

• vendor/bin/hh-autoload will ignore type errors. This is useful if your type errors are because codegen needs updating
• don't include tests in release zips
• move PHPUnit HHIs to -dev dependency

Use hhvm/type-assert to avoid composer warning

fredemmott/type-assert has moved to hhvm/type-assert; dependency updated.

Support relative paths, improved PSR support

• hh_autoload.php will now create paths relative to the directory it is generated in, instead of using absolute paths by default. The old behavior can be selected by setting the relativeAutoloadRoot option to false in hh_autoload.json
• vendor directories using PSR paths without trailing slashes are now supported

Thanks to @simonwelsh for both of these improvements.

Support dev-only roots, add standalone executable to update map

• added 'devRoots' option to JSON config
• composer plugin now uses roots and devRoots unless --no-dev is passed
• added bin/hh-autoload (usually available as vendor/bin/hh-autoload) to regenerate the map, which also understands a --no-dev option
• tested in HHVM's PHP7 mode (PHP5 mode is still supported)
• friendlier errors when configuration loading fails
• ext-factparse is now the default parser, when available; if this causes problems, please file an issue, and you can revert to definition-finder by setting the parser option in your hh_autoload.json

Fix configuration option for ext-factparse support

In v1.3.0, the factparse support could be directly used by creating the appropriate classes, but the configuration option did nothing.