-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify puli.json #173
Comments
I agree 100%.
What is the use-case of this?
That's a good idea. What about using the same name in the CLI? Globally, I think it's a great idea. Most people tend to edit JSON files by hand and don't use CLI, we should try to simply their job :) . |
This is awesome, all of this! I like using the CLI but as you said, many users would rather edit the file themselves.
Is it (will it be) possible to disable completely a module? Why I ask this: in some frameworks (e.g. Symfony) you register bundles/modules explicitly with code which leads to a 2 step install:
I started playing with a simpler process based on Puli: install the package, and that's it. However I need to offer a way to users to disable a module (without uninstalling it). I may be going a wrong path (explicitly enabling a package is probably better) but I'd like to know if Puli can offer that. |
@mnapoli We can easily add a way to disable packages, e.g. (similarly to "override"): {
"disable": [
"vendor/package",
]
} |
We could also rename "override-order" to "reorder". This option can already be used to tell Puli to load a package "a" before a package "b": {
"reorder": [
"vendor/a",
"vendor/b",
]
} Note that you don't need to include the names of any other installed packages (e.g. "c", "d" and "e") in this list if you don't want to. One possible caveat: At the moment, packages that are loaded later override packages that are loaded earlier. So if "a" and "b" contain a resource mapped to the same Puli path, the one from "b" will be preferred. Is this expected? |
To me it makes sense. What would happen to packages not defined in "order": do they get appended to the list or prepended? |
@mnapoli That's undefined. The only guarantee we make is that packages are loadedin an order that respects all the "override" keys and the "reorder" key in the root package. |
Like it! 👍 |
This is WIP in puli/manager#56 |
Right now, we mostly recommend to use the Puli CLI for configuring Puli packages. Unfortunately, using CLI programs is a problem for many developers. Therefore I propose to simplify the puli.json schema in order to make it more accessible to a larger crowd of developers.
Thanks to our JSON migrations (#96), we can do this without breaking any existing projects.
One step in this direction is described in #167.
Furthermore, I think we should rename "path-mappings" (back) to "resources", which seems easier to understand:
In addition, a "resources-dev" key should be added for resources that are only loaded in the development environment.
The entry "bindings" should be renamed to "provide" and restructured as follows:
Equally, "provide-dev" should be added for development-only bindings.
When an artifact should be bound to multiple types, we can use an array:
If a binding type has parameters, we can change the simple type string to an object:
This will have a few consequences:
It will not be possible anymore to disable bindings, since we don't store UUIDs anymore by default. I don't think this feature is highly needed.
Each binding type will only accept one kind of artifact (e.g. class or resource or ...) that is defined with the binding type:
Depending on the artifact accepted by a binding type, we can construct the right binding class (ResourceBinding, ClassBinding, ...) for the LHS of "provide". New artifacts types can be added by providing implementations of a new
BindingFactory
interface (replaces Add BindingSerializer interface #171) or similar:Disclaimer: I don't think adding ServiceBindings is the best example, since containers usually offer better approaches to solve this problem. I can'think of any better though right now.
Opinions?
The text was updated successfully, but these errors were encountered: