Future release plans (yikes spring / summer '20); have a question or comment on new features drop it here!

[typhonrt]

Hi folks I just want to make a note that a major revision of typhonjs-escomplex will be in the works during late summer / fall this year completing and enhancing functionality. This issue tracks the major enhancements and provides a road map toward a non-alpha release in the fall or thereabout.

There are a few major changes planned. The first is to update the AST generation / parsing to Babylon 7 (6 is currently used) and cover any new stage 2+ proposals. The second is a potential major overhaul to the execution environment of typhonjs-escomplex such that it can work in conjunction with other AST parsing tooling simultaneously. The last major feature is to support Typescript via Babylon 7 and process all new AST nodes to provide complexity reports for TS and JS code.

While backward compatibility of current report generation will likely be maintained a large goal is to find a clean way to integrate complexity report generation along side a documentation generation tool which I'm also maintaining, TJSDoc, via a common AST generation / parsing runtime. Both of these tools parse the AST tree of source code, but TJSDoc builds a comprehensive DB structure (TaffyDB) instead of a nested JSON dump of generated data. Ideally the outcome of this major enhancement is to provide a shared runtime where both tools can execute simultaneously and build respective DBs of documentation and complexity information where the documentation DB has a reference to the complexity DB for all documented nodes. This is a big task, but one worth tackling as it is not efficient or easy to map the current static report generation of typhonjs-escomplex separately. The great result for TJSDoc will be complexity information linked to the doc DB providing coherent display of complexity info in a documentation tool. 3rd parties will be able to create plugins for TJSDoc to display complexity information in interesting ways attached to doc and source code data / repo references, etc. It will be possible to still use typhonjs-escomplex standalone as well though the report format may change for the next major release.

I'll refine this issue as a task lisk presents itself toward the end of summer, but wanted to define the 3 major enhancements that will drive things towards a non-alpha release.

[sgb-io]

Hi @typhonrt are you still planning to get round to this? Thanks for your work so far

[typhonrt]

It is true that I have pushed back my return to OSS work a bit longer, but plan to get back to things full time at the end of the month. An interim 0.1.0 release has been made which fixes quite a few things including latest code AST parser. A 0.2.0 release of typhonjs-escomplex will be released at end of January and likely be the last release for the current NPM module except for future parser updates. All new work for the next significantly updated version of typhonjs-escomplex described in this issue above will be done in the @typhonjs/escomplex NPM module. This will allow legacy packages to keep consuming the current report structure with just maintenance updates for major new babel-parser versions.

@sgb-io I'd be glad to hear of your use of typhonjs-escomplex if it is beyond plato integration which is the biggest downstream consumer right now.

[sgb-io]

Thanks for the update. I can't see any maintained alternative right now so I think this project is of some importance, I'll be glad to contribute where I am able to (although my knowledge and expertise around SA & AST is very limited).

[davidhouweling]

@typhonrt any update as to when the @typhonjs/escomplex module would be available?

[typhonrt]

Hi @davidhouweling!

Indeed things have stalled as I've been on an extended sabbatical. Lucky enough to extend it another 9 months. I got hardcore burnt out, but made it to 40 before the implosion. Indeed I intend to continue to work on @typhonjs/escomplex especially in conjunction for interoperability with TJSDoc / documentation tooling. Hopefully I can muster some time to do an analysis of regressions with the latest version updated Dec '18 and get a patch out in coming months and get things updated for any downstream consumers.

As mentioned though I just decided to spend the majority of the next 9 months making an effort to get to the semi-pro / pro level for pool / billiards and won't get full time coding in though I plan to get some things moving forward; it's been a slog and taking quite a bit of time! Hopefully next April / May will see me getting back into full swing of things, but it would be nice to get a release out sooner than that fixing a handful of regressions.

Like most open source efforts of any complexity work on typhonjs-escomplex cost me way too much money ~$20k (~4 months full time+ effort) already and there is no / minimal hope of ROI. So long answer short; yes I plan to get back to things full time though it might still be a while.

[iegik]

@stepsize, we need help here

[typhonrt]

@Stepsize, we need help here

There is a lot of promise for an OSS solution for JS / TS complexity analysis. typhonjs-escomplex is a hard fork of escomplex the latter of which got abandoned in 2015. The "hand me down" steward of escomplex at the time just wasn't agreeable to try and work with as things went... I certainly made a lot of progress with my continuation, but eventually had to stop active work. OSS can be quite brutal.

As mentioned recently in #33 I am angling towards spending ~2 weeks in Q1 next year ('23), hopefully sometime in January, to update all dependencies and rework the repo / org / project structure. I'll likely be converting the build over to a mono-repo (NX powered perhaps) and moving all repos from the separated repos of this organization to a single repo via typhonjs-escomplex.

I am not going to be able to continue improving the complexity analysis, but I should at least get the effort into a bit more maintainable state as a mono-repo and native ESM package along with debugging any changes in AST processing when testing against the current versions of the JS / TS AST generators available.

[missvalentinep]

@typhonrt Hi, thank you for the project!

I see you talking about refactoring in '23. Do you have any ETA?
Is there perhaps any help that we can offer?

[typhonrt]

@typhonrt Hi, thank you for the project!
I see you talking about refactoring in '23. Do you have any ETA? Is there perhaps any help that we can offer?

There definitely is interest which is good to hear about.

I was working remotely the past couple of months and upkeep / continued work on active projects and PRs submitted to Svelte took up my dev time. I'm back at my home base as of yesterday. I initially planned on putting some of the active projects on hold to update this project in the past couple of months, but active projects have a way of staying active. I do have a window for a lot of OSS dev in the next ~3+ months that I'm working out a schedule. An off the cuff ETA could see the re-architecture work done on this project in the May / June timeframe. It will likely be a solid 2 week block of time (~120-160 hours). I should be able to get other active efforts wrapped up in April to clear out this chunk of time.

It is hard to plan / coordinate the architecture changes that I have in mind for typhonjs-escomplex as far as getting multiple folks involved especially considering the aging state of things (IE a 2017 circa way of organizing the package and the non-standard many-repo approach). I do have all the experience / modern understanding for ESM / Node to get things going in the right direction.

After modernizing the architecture I'd be thrilled to get as many contributors onboard that can continue the process of refining the metric gathering especially for any new language features. For instance there is nothing specific in regard to gathering metrics on Typescript code or handling anything specific to TS AST nodes. I also predominantly work w/ Svelte these days so adding the ability to parse Svelte files is a curiosity. That also opens the door to dare I suggest metrics gathering on CSS usage; while interesting, this certainly is not on the roadmap at this time.