You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't want to comment work which is yet under process. But because I am watching I want to comment this ComposerScripts.php#25 ..
Its really bad idea to have such direct dependency of some 3rd party library. If there is any change of this library it should not be applied automatic into the system as it can break it.
P.S. At the same time if just 1 exact version is used of this Zend why do we have to copy it from the vendor each time when composer update is runned..
Per composer.json, it limits it to generally non-BC breaking versions. It's always possible that there will be a break, but very unlikely, especially coming from a company like Zend.
While we won't use very many third-party libraries for the reasons you mentioned, there are times where it's extremely practical to use one, and fool-hardy not to. This is one of those cases. Proper escaping of output is an extremely complex problem. Zend has done the best job of anyone I could see out there of catching all of the edge-cases and complexities into a good library. For us to recreate that particular wheel would be silly. And dangerous to those using CI thinking it helps them be secure.
And we're not limiting to one exact version of the library. It follows semantic versioning so could be anything between 2.5 and NOT 3, so bug-fixes and enhancements can come along. That's why we check every time an update is ran and copy the new over if so.
The file is moved over, instead of leaving it in place for Composer to manage, because of one of the requirements of the framework: People have to be able to download the library and go. No Composer needed. This gets the file in place and usable without so that when releases are eventually created, everything's ready.
"Zend\Escaper was written with ease of use in mind, so it can be used completely stand-alone from the rest of the framework, and as such can be installed with Composer using zendframework/zend-escaper."
This component is intended to be usable stand-alone, and does not bring in any of the complexity normally inherent in using third party components.
@lonnieezell I understand your idea. How ever an auto updating Core sounds not stable !
A lot more stable will be the Update of any 3rd party component as this Zend Escapare to be made by the staff and pushed as small sub release of CI.
"The file is moved over, instead of leaving it in place for Composer to manage" - all who use composer will have auto updating Escaper on each Zend Escaper new version and the others which don't use Composer and they update manually instead, will have older Escaper version with the new CI ?
@sv3tli0 I understand your concerns, and it's something that we'll definitely keep an eye on and modify if needed. However, I think you'll find that as long as it's carefully done, it is fine. That's the beauty of Composer and Semantic versioning. One of the most popular PHP frameworks, Laravel, currently works this way with around 25 third-party libraries used as part of the core of the framework, all installed via Composer during install/update.
all who use composer will have auto updating Escaper on each Zend Escaper new version and the others which don't use Composer and they update manually instead, will have older Escaper version with the new CI?
More or less, yeah. With each tagged release it will have the current version of Escaper. If you use Composer, then you get bug-fixes and security fixes faster. If you're pulling from the develop repo directly through git then, yes, you run the risk of having a not up-to-date version of Escaper, but that's the risk using a 'develop' branch and not using a stable release.
Activity
jim-parry commentedon Nov 5, 2015
+1
sv3tli0 commentedon Dec 2, 2015
I don't want to comment work which is yet under process. But because I am watching I want to comment this ComposerScripts.php#25 ..
Its really bad idea to have such direct dependency of some 3rd party library. If there is any change of this library it should not be applied automatic into the system as it can break it.
P.S. At the same time if just 1 exact version is used of this Zend why do we have to copy it from the vendor each time when composer update is runned..
lonnieezell commentedon Dec 2, 2015
Per composer.json, it limits it to generally non-BC breaking versions. It's always possible that there will be a break, but very unlikely, especially coming from a company like Zend.
While we won't use very many third-party libraries for the reasons you mentioned, there are times where it's extremely practical to use one, and fool-hardy not to. This is one of those cases. Proper escaping of output is an extremely complex problem. Zend has done the best job of anyone I could see out there of catching all of the edge-cases and complexities into a good library. For us to recreate that particular wheel would be silly. And dangerous to those using CI thinking it helps them be secure.
And we're not limiting to one exact version of the library. It follows semantic versioning so could be anything between 2.5 and NOT 3, so bug-fixes and enhancements can come along. That's why we check every time an update is ran and copy the new over if so.
The file is moved over, instead of leaving it in place for Composer to manage, because of one of the requirements of the framework: People have to be able to download the library and go. No Composer needed. This gets the file in place and usable without so that when releases are eventually created, everything's ready.
jim-parry commentedon Dec 2, 2015
"Zend\Escaper was written with ease of use in mind, so it can be used completely stand-alone from the rest of the framework, and as such can be installed with Composer using zendframework/zend-escaper."
This component is intended to be usable stand-alone, and does not bring in any of the complexity normally inherent in using third party components.
sv3tli0 commentedon Dec 2, 2015
@lonnieezell I understand your idea. How ever an auto updating Core sounds not stable !
A lot more stable will be the Update of any 3rd party component as this Zend Escapare to be made by the staff and pushed as small sub release of CI.
"The file is moved over, instead of leaving it in place for Composer to manage" - all who use composer will have auto updating Escaper on each Zend Escaper new version and the others which don't use Composer and they update manually instead, will have older Escaper version with the new CI ?
lonnieezell commentedon Dec 2, 2015
@sv3tli0 I understand your concerns, and it's something that we'll definitely keep an eye on and modify if needed. However, I think you'll find that as long as it's carefully done, it is fine. That's the beauty of Composer and Semantic versioning. One of the most popular PHP frameworks, Laravel, currently works this way with around 25 third-party libraries used as part of the core of the framework, all installed via Composer during install/update.
More or less, yeah. With each tagged release it will have the current version of Escaper. If you use Composer, then you get bug-fixes and security fixes faster. If you're pulling from the develop repo directly through git then, yes, you run the risk of having a not up-to-date version of Escaper, but that's the risk using a 'develop' branch and not using a stable release.
Error if the table haven't primary key