Would you consider splitting flowscope-core into smaller crates with narrower responsibilities?
The current internal structure is already well organized, but from a downstream user's perspective the package boundary is still fairly monolithic.
For example, there are plausible use cases where someone may want to depend only on:
- SQL lineage analysis
- SQL formatting / rewriting
- dialect semantics and identifier normalization
- schema-aware analysis
without pulling in the rest of the core functionality such as linting, completion, templating, or other higher-level analysis features.
A structure along the lines of:
flowscope-semanticsflowscope-lineageflowscope-schemaflowscope-core as a higher-level facade
could make FlowScope's existing semantic work much easier to reuse in other Rust tools.
My particular interest is using the lineage engine as a library dependency. The current implementation looks quite capable, but depending on all of flowscope-core just to consume lineage makes integration less attractive than it otherwise would be.
I think this could also broaden FlowScope's role from being primarily a product core to being a reusable SQL tooling ecosystem.
Would this kind of crate-level decomposition fit the project's direction?
Would you consider splitting
flowscope-coreinto smaller crates with narrower responsibilities?The current internal structure is already well organized, but from a downstream user's perspective the package boundary is still fairly monolithic.
For example, there are plausible use cases where someone may want to depend only on:
without pulling in the rest of the core functionality such as linting, completion, templating, or other higher-level analysis features.
A structure along the lines of:
flowscope-semanticsflowscope-lineageflowscope-schemaflowscope-coreas a higher-level facadecould make FlowScope's existing semantic work much easier to reuse in other Rust tools.
My particular interest is using the lineage engine as a library dependency. The current implementation looks quite capable, but depending on all of
flowscope-corejust to consume lineage makes integration less attractive than it otherwise would be.I think this could also broaden FlowScope's role from being primarily a product core to being a reusable SQL tooling ecosystem.
Would this kind of crate-level decomposition fit the project's direction?