This repository has been archived by the owner on Jan 21, 2020. It is now read-only.
forked from samsonasik/expressive-composer-installer
-
Notifications
You must be signed in to change notification settings - Fork 90
Prepare for RC6 #60
Merged
weierophinney
merged 3 commits into
zendframework:master
from
weierophinney:hotfix/expressive-rc6
Jan 19, 2016
Merged
Prepare for RC6 #60
weierophinney
merged 3 commits into
zendframework:master
from
weierophinney:hotfix/expressive-rc6
Jan 19, 2016
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
See zendframework/zend-expressive#270 for details behind the configuration changes. |
Evidently, you must pass the |
Pinging @mwillbanks, @ezimuel, and @danizord for review. |
Looks good 👍 |
Sets the version constraint for zend-servicemanager to `^2.7.3 || ^3.0`, to allow usage of either version. Initial selection will be based on other dependencies. Users can override later to select a more specific version.
Need the 2.0 version going forward. This also means new configuration for the middleware pipeline. Per zendframework/zend-expressive#270, this patch updates the middleware pipeline to be an array of middleware specifications, each with a priority. It defines three specific pipelines: - "always" is registered at priority 10000, and represents a pipeline of middleware that acts as either pre-conditions or post-routing handlers (e.g., CORS support, WWW-Authentication header injection, etc.). - "routing" is registered at priority 1, and defines a middleware pipeline containing the routing, UrlHelper, and dispatch middleware; any middleware that you might want to have intercept the results of routing could go between them. - "error" is registered at priority -1000, and defines a middleware pipeline for error handlers.
Otherwise the dev requirements *before they are rewritten by the installer* are used. Also provides a note detailing how to install the dev requirements after installation.
weierophinney
force-pushed
the
hotfix/expressive-rc6
branch
from
January 19, 2016 14:34
7e19ecb
to
cf17bc2
Compare
weierophinney
added a commit
that referenced
this pull request
Jan 19, 2016
weierophinney
added a commit
that referenced
this pull request
Jan 19, 2016
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch provides a few changes to prepare for RC6:
^2.7.3 || ^3.0
, to allow users to select the version they want to use. Configuration already works with either.^2.0
, as that's the version compatible with zend-expressive RC6.middleware_pipeline
to follow the changes in zend-expressive RC6, providing a list of middleware specifications with priority values, and creating the following specific definitions:I've cloned and installed from the local branch with these changes, and all works as expected, with one exception: I discovered that an install installs the development dependencies as defined prior to the installer script acting. This means that every renderer and every router is installed at first. Running
composer update
immediately following an install corrects the situation, but it's not ideal. The situation likely pre-existed these changes, as I didn't change the installer scripts, and, as such, I'm not including a fix for that behavior at this time.