mcstreetguy / fusion-debugger Goto Github PK

Describe the bug
Currently, if the debugger encounters a nested prototype definition it cannot handle it properly. Instead, the meta key containing these definitions remains in the otherwise flattened debug-view. This is no real issue as the overview is still correct, but as the information is unstyled it looks really messy...

We have not found a clear remedy to this problem currently. See our thoughts on this below:

• One option would be to include modified properties if the corresponding prototype is used somewhere below the current level. This could be problematic as nested definitions also apply to furtherly nested prototypes and we would need to pass them around between recursions, which will most likely result in unexpected behaviour in some way.
• Another possibility would be to append the modifications to the internal prototype definitions but this would introduce a whole new world of complexity, as we would need to differ between nesting-levels within protoype definitions and this would either be very time- or resource-expensive!
• The third solution would be to simply keep the information where it is, but to style it in some way (colorization, etc.) to make it at least prettier if we cannot integrate it reasonably.

To Reproduce
Steps to reproduce the behavior:

1. Create some prototype definition
2. Create a nested prototype definition inside of the freshly created prototype
3. Have a look at the debug-view of the topmost new prototype

Expected behavior
Nested definitions should not be ignored totally.

Environment (please complete the following information):

• OS: Ubuntu 16.04
• Terminal: Bash
• PHP: 7.0.33-0ubuntu0.16.04.5
• Flow: v4.3.19
• Neos: v3.3.24

Describe the bug
In some cases the library interprets the number 0 as the null constant, resulting in the overview showing <empty> for the property, even if it should actually be a numeric value.

To Reproduce
Steps to reproduce the behavior:

1. Create a prototype and assign one of it's properties the static value 0
2. Run the debugger on that freshly created prototype
3. Have a close look on the 0-property in the tree view, it will say <empty>

Expected behavior
This exceptional case should be considered in the processing of the prototype definitions so that 0 is recognized as this value and not as a missing value.

Screenshots
The elementIndex property is initialized with the value 0, but see the output below:

(sensitive information has been censored in the image.)

Environment (please complete the following information):

• OS: Ubuntu 16.04
• Terminal: bash
• PHP: 7.0.33-0ubuntu0.16.04.5
• Flow: v4.3.19
• Neos: v3.3.24

Currently, when unsetting a path in Fusion through my.path > the engine sets a meta-key for that path, named __stopInheritanceChain, to identify such "emptied" values. That key is currently not flattened by the plugin. Would be better if it could be parsed too.

Verified with neos/fusion v5.3.0

Describe the bug
Currently, if a syntax error is present in one of the Fusion files and you make the plugin lint them, it reports multiple errors in several files if the corresponding errorneous file is included somewhere (e.g. in Root.fusion)

To Reproduce
Steps to reproduce the behavior:

1. Create a syntax error in one of your fusion files that is included in another
2. Execute the fusion:lint command
3. Have a closer look at it's output

Expected behavior
The linter should only report the error in the actual source file, not in a file that actually includes the problematic code and does not actually contain it. This can be very confusing if you want to fix a syntax error that's simply not present.

Screenshots

(as you can see, it's the same error and message in both files.)

Environment (please complete the following information):

• OS: Ubuntu 16.04
• Terminal: bash
• PHP: v7.1
• Flow: v4.3.21
• Neos: v3.3.25

Is your feature request related to a problem? Please describe.
Currently you need to define the namespace mappings for the plugin manually in the Settings.yaml. This is kind of obsolete as the plugin could also read all namespace declarations from the fusion code it need's to parse either way.

Describe the solution you'd like
The plugin could collect namespace definitions during runtime directly from the loaded fusion code instead of loading these mapping from the config.

Is your feature request related to a problem? Please describe.
Currently, the colored output of the fusion:debugprototype command appears badly readable in several terminals, depending on their individual color scheme.

Describe the solution you'd like
It would be great, if some could configure the used colors to fit their personal environment.
Such that in e.g. the Settings.yaml one could change some color codes to be more readable.

Describe alternatives you've considered
Alternatively we could provide a "color scheme" setting with several predefined schemes the user can choose from. This could be even an addition to the override-approach, where the user can first select a theme but still override single colors if needed.

Additional context
See this screenshot as an example:

• The dark blue property names are nearly invisible
• The yellow prototype names are way too eye-catching
• The red meta-properties have a far too high contrast to "normal" properties.

The example in my case may be particularly extreme and possibly not representative, but I find that a single counter-example is sufficient to justify this function meaningfully. Debugging should work well in any environment, regardless of the shell, terminal program, or color scheme. Of course you can also switch off coloring completely with the `--no-color' option, but I think this is no real alternative because the results are so much harder to read.

Is your feature request related to a problem? Please describe.
This improvement only targets convenience.

Describe the solution you'd like
It would be a huge improvement to the debugger if one could see the prototype information directly from within the backend, just like the "Configuration" backend module but for Fusion definitions respectively.

Maybe with this api one would need less to rewrite. I just saw that youre not using it...
https://github.com/neos/neos-development-collection/blob/master/Neos.Neos/Classes/Domain/Service/FusionService.php#L136

But then one couldn't use this package outside of neos...

Is your feature request related to a problem? Please describe.
Currently, the output of the debugger lists all nested prototypes used, but their contents are not visible. This means I have to execute the command several times and put the results together myself to be able to reconstruct my prototype in detail. It would be much more practical for this case if the debugger could already merge this information itself.

Describe the solution you'd like
There should be an option added to fusion:debugprototype, that forces the Debugger to recursively resolve all used prototypes, instead of only merging the root inheritance chain. I propose to name it --resolve-all in coherence with it's functionality.