Question about reusing the name "unist" (and|or releted names) for a PHP port

[overclokk]

Hi,

I hope you're doing great! I'm a PHP developer working on a CLI tool for scaffolding files. I stumbled upon unist while exploring AST concepts for my project and found it really interesting. I'm considering porting the unist interfaces to PHP and using them in my project. Since unist is under a Creative Commons license, I wanted to check with you if you'd be okay with me also reusing the name 'unist' (or any related names in this project), or if you'd prefer that I choose a different one. Let me know what you think!

Thanks a lot!

[wooorm]

Hi! Sure: if you intend to follow unist, then using that name is fine. Though, I would recommend also having a practical implementation (mdast/hast/xast/nclst/etc). Take for example https://github.com/wooorm/markdown-rs in Rust, it has a name (markdown-rs), it can spit out mdast (which is based on unist), so in its API names and readmes it uses that term (mdast), and unist itself is mostly an internal thing

[overclokk]

Thanks a lot!

I'm indeed working on a practical implementation for Markdown right now, with the goal of supporting other file types in the future. I started with Markdown because it's the most documented format I could find and there are many examples available, which makes it ideal for learning. My main interest is in manipulating the AST and supporting round-trip transformations (File → AST → File), but I’m also planning to implement conversions to HTML as part of the project. I'm still in the learning and experimentation phase, but that's the long-term direction.

Of course, it won’t be a 1:1 port — the internal logic will differ due to the nature of PHP — but I’m aiming for compatibility with the structure of ASTs defined by both unist and mdast. For Markdown specifically, I’m following the mdast specification closely, so the nodes produced will match its shape and naming conventions as much as possible. That way, even if the internals are different, the resulting tree will be recognizable and interoperable with the mdast format.

For example, here’s what the PHP version of the unist base interfaces currently looks like, translated into interfaces, traits, and classes:

.
├── DataInterface.php
├── LiteralInterface.php
├── LiteralTrait.php
├── NodeInterface.php
├── NodeTrait.php
├── NullDataTrait.php
├── ParentInterface.php
├── ParentTrait.php
├── Point.php
├── PointInterface.php
├── Position.php
├── PositionFactory.php
└── PositionInterface.php

As for Markdown-specific nodes, I’m building concrete classes instead of interfaces based directly on the mdast specification.

Thanks again for your work and the helpful response!

[wooorm]

I do recommend looking at actually porting, basically 1-to-1. There’s 14 years of work in these JavaScript projects. They are tested well. Used billions of times. 100s of projects. You’d throw the baby away with the bath water!

Or: do things in JS. Or, in Rust, compile it?

[overclokk]

I'll try to do my best 😊

[ChristianMurphy]

PHP can bind to rust
https://github.com/davidcole1340/ext-php-rs
https://davidcole1340.github.io/ext-php-rs/

You could use https://github.com/wooorm/markdown-rs which is faster than PHP probably could achieve.

[ChristianMurphy]

And if you port code or bind to the existing, consider adding a notice file https://infra.apache.org/licensing-howto.html to the project.