[Suggestions] Various improvements (backwards compatible) #154
Sophist-UK
started this conversation in
Ideas
Replies: 1 comment
-
On reflection, point 1. is already possible but undocumented. Point 2. would lose details of the directory the sub-class of PackageServiceProvider is located in, and cannot easily be implemented. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
The
setBasePath()
method is called in theregister()
method of thePackageServiceProvider
class and thus cannot be explicitly set against thePackage
instance when it is created. This is based on an assumption that the PackageServiceProvider subclass is located in a sub-directory e.g./Providers
whereas it could be in/App/Providers
or/
. I would propose that the current defaultbasePath
is set in thePackage
constructor rather than inregister()
and thus can be overridden in the user'sconfigurePackage()
code like any other value.The basePath is set to e.g.
/Providers
rather than/
and then e.g. theconfig
directory is../config
. I think it would be better to set the basePath to be/
and have directories relative to that. SincesetBasePath
is currently user callable inConfigurePackage()
this change can currently be made backwards compatible.You can then have new methods (e.g.
setConfigPath
) to define the relative paths for config, migrations etc. in order not to rely on hard coded assumptions about directory structure. (You would obviously need to have default values that could be overridden.)hasConfigFile
andhasViewComposer
accept either a string or an array of strings, whilst most other methods have singular & plural versions to do the same thing, and this is inconsistent. I would suggest that all singular methods are changed to be mixed, and plural methods are synonyms.Where methods take individual files (rather than directory/directories) as a parameter, it would be nice to provide the ability to specify
'*'
or**
as a file name, and for the package to iterate over suitable file names so that they do not need to be specified explicitly.There are no type-hints for this package and IMO they would be beneficial.
Beta Was this translation helpful? Give feedback.
All reactions