RFC: dgeni.next

Here are my thoughts on the next version of dgeni.

Immutable data structs

I think these should have the additional restriction that you can only set keys on an object; you can’t delete or modify them.

I think using Object keys instead of string keys would improve refactoring.

If we’re using ES6 module syntax, and tokens to access keys in steps in the processor, we could even go as far as using static analysis to determine the partial ordering of steps in the pipeline.

Transducers

See: http://jlongster.com/Transducers.js--A-JavaScript-Library-for-Transformation-of-Data

This should be an implementation detail, and invisible to end users. tl;dr– we can avoid some intermediate work.

I think this implementation is most promising: https://github.com/cognitect-labs/transducers-js

Building the pipeline: Constraint solver vs. explicit ordering

There are two ways to build up a pipeline:

• specify prereqs and find partial order (what dgeni currently does)
• build the pipeline yourself (what gulp does, for instance)

We should consider the second approach. But we should be weary of repeating gulps mistakes– we should not re-run common steps if they appear more than once.

Instead, we should use explicit pipelines to do partial ordering when “merging” pipes.

TypeScript

We should write it in TypeScript. Types are a-ok.

Developer experience

• Debugging should be easy
• We should have a way to dump out the order of all the tasks

Templates

There should only be one set of templates used at the end of the generation process. Currently, there’s some inheritance system that makes it hard to determine which template is actually used.

[tommck]

I’ve been so looking forward to getting a refactoring of this project because I find the documentation/usage to be REALLY convoluted.

For instance, I can’t even figure out how to document components. I figured I might just be able to add a template, but that doesn’t seem to work.

Any tips/tricks?

[petebacondarwin]

I would love to but just don’t have the capacity right now to do such major work on the library. dgeni and dgeni-packages are in significant use throughout the angular 1 and angular 2 projects (and a number of other projects), so it is by no means abandoned in general. Just not enough time to think about significant rewrites.