Allow generating lenses with module instead of namespace, or without either
cmeeren opened this issue · comments
My codebases are mostly single-project ASP.NET Core apps and don't use namespaces, only modules. It seems like the lens generator forces a namespace. It should be possible to generate with a module instead of a namespace. Ideally, especially if #145 is implemented, it should be possible to generate only the lenses and no namespace/module.
This could be a general property that could be added to all plugins or specific to the lens plugin, all plugins currently take a namespace property in the myriad.toml file. I forget what happens if thats empty...
Ah, lens plugin gets a namespace named UnknownNamespace is its empty
Same with the fields and DU's plugin, there could be a hierarchy, namespace, module, if both of those are empty then the generation occurs in the root, which might potentially mean an invalid ast. I think namespace, module, then root would work as a rule though, its up to the plugin authors to enforce any rules currently as nothing is set or used in myriad.core etc.
I found an issue with generating with a module rather than a namespace.
Modules can be either top-level or nested, top-level modules cannot have comments above them and are defined with no = on the definition. Nested modules are defined by using an = after the module definition. Each plugin is independent and knows nothing about any previous plugins so it's not possible to know whether one plugin is defined at the top level and others are nested so this becomes a bit messy. Unless you generate plugins self-contained with their own namespace so the namespace requirement is by design, I rediscovered this on trying to implement modules rather than namespace generation.
Plugins could allow you to specify the exact string that appears there: "module Foo.Bar", "namespace Baz", etc. Facil does that.
The ast has two constructs one for top-level modules, which is one per file, and another for nested modules, which are any subsequent ones. there are also anonymous modules for script files, I'm still hacking away but it doesn't look like I'm getting anywhere.
Only top-level modules can have a path like module xxx.yyy, nested ones are only allowed to be a simple path like module xxx =
Inline is probably different but there are issues with getting the indentation correctly aligned etc and knowing if you are inside a type or module or namespace already, complexity there.