[split] CodeIgniter Vision

I made a small survey at the company I work for, about what is our wishes for the future.
What do you think about it?

CodeIgniter 3.1

• Managing application and third party tests
  
• Prettier, user friendlier docs
  
• Creating foreign keys with migrations
  
• Creating indexes with migrations
  
• Database seeding
  

CodeIgniter 4.x

• Using PHP 5.3 without the eye candy (PSR etc… these "conventions" not fully fit to CI's way); Currently PHP 5.3 is almost officially legacy, so with supporting it, CI continues to be the legacy environment friendly framework as always
  
• Modules and HMVC support
  
• Removing segment based routing and require routes to exists in the main routes.php or in a per module route definition file
  
• Supporting view presenters
  
• Running migrations and seeds per module
  
• Events (like github.com/nathanmac/CodeIgniter-Events)
  
• Console (for running migrations, scaffolding and custom commands)
  
• Namespaced code to enable the reuse of class names and optimize loading (I think manual $this->load is enought PSR-0 or PSR-4 autoload is too much)
  
• RESTFull routing
  
• Advanced profiler (like github.com/lonnieezell/codeigniter-forensics)
  
• Routing filters
  
• Delete compatibility codes and checks
  
• Replacing Template Parser lib with a widely supported one (Handlebars maybe to achive client and server side compatibility too) or delete it
  
• Reanimate Sparks as packages dedicated to CI; these can be special composer compatible packages or custom (like in Symfony 2 or Laravel 4 bundles)
  
• Integrated Sparks package manager
  
• Diffrent CodeIgniter distributions:
  • Minimal: only the core (routing, mvc, etc.)
    
  • Standard: core + main libraries
    
  • Full: the current all in one distribution
• ORM (maybe as a Spark)
  
• NoSQL support (maybe as a Spark)
  
• Message queue support (as a Spark?)
  
• Deleting (or convert to Sparks) the useless, rarly used libraries (cart, javascript, table, trackback, xmlrpc, xmlrpcs etc) and helpers (capcha etc) and stuff (fonts)
  

I'm confused what you mean about the foreign keys and indexes in the migrations. You can always use any SQL you need to - and you're typically only targeting a single database type, right? Also, dbforge already supports adding indexes if you use dbforge when doing migrations.

Also confused about the "managing application and third-party tests" part. How would you want CodeIgniter to handle that? That's more between you and the testing suite you use, right? I mean you need a slightly different setup depending on whether you're using PHPUnit or CodeCeption or SimpleTest.

Support Development •  CodeIgniter 4 Foundations • Practical CodeIgniter 3  • CodeIgniter Tutorials

I'm confused what you mean about the foreign keys and indexes in the migrations. You can always use any SQL you need to - and you're typically only targeting a single database type, right? Also, dbforge already supports adding indexes if you use dbforge when doing migrations.

Also confused about the "managing application and third-party tests" part. How would you want CodeIgniter to handle that? That's more between you and the testing suite you use, right? I mean you need a slightly different setup depending on whether you're using PHPUnit or CodeCeption or SimpleTest.

Yes, I can run custom queries with $this->db->query(), but that is not platform independent. We work for clients who has different type of RDBMSs or not have any: our migrations have to be runnable on MySQL, Postgres and SQLite too. CI3 docs not mention anything about how to create unique or full text indexes, you can create a primary key or a simple index, but its limiting a bit.

CodeIgniter 3 uses PHPUnit as we are, and I think CI should encourage to use that. We need main application tests (application/tests) and module tests which contains the tests and mocks for libraries and models. In the user defined tests we can access all of CI's mocks and we can load mocks from the main application or a module, maybe the loading of mocks should be automatized in some way. If you run the tests on a site, the CodeIgniter and the application specific tests also runs. Later a DOM crawler (for example Mink) should be introduced to test the output of controller actions, but thats a different story...