This is a proposal that needs further discussion before implementing.
Currently, the importFrom attribute of link nodes such as DefinedTypeLinkNode enable users to opt-out of defining the type using TypeNodes and instead grab them from a hooked folder or a named module (such as a package for JS or a crate for Rust using a dependency map).
Whilst this enables renderers to inject "custom types" into the generated code, it is a hole in the information tree and something that will affect explorer or anyone else requiring that information.
This issue propose that we no longer allow link nodes to "link outside of the tree" to avoid information loss.
As for enabling custom type injection for renderers, this could be achieved using special renderer options that lets the visitor know which defined type should be replaced by a custom one. This may even be a better outcome as it'll allow each renderer to decide if they want to inject custom code or not.
This is a proposal that needs further discussion before implementing.
Currently, the
importFrom
attribute of link nodes such asDefinedTypeLinkNode
enable users to opt-out of defining the type usingTypeNodes
and instead grab them from ahooked
folder or a named module (such as a package for JS or a crate for Rust using a dependency map).Whilst this enables renderers to inject "custom types" into the generated code, it is a hole in the information tree and something that will affect explorer or anyone else requiring that information.
This issue propose that we no longer allow link nodes to "link outside of the tree" to avoid information loss.
As for enabling custom type injection for renderers, this could be achieved using special renderer options that lets the visitor know which defined type should be replaced by a custom one. This may even be a better outcome as it'll allow each renderer to decide if they want to inject custom code or not.