[RFC] Naming issue

[KillyMXI]

I plan to release a new companion package that converts html to valid markdown rather than arbitrary text (was planned for simultaneous release with v9 but is going to be delayed). There is a potential for packages targeting different output formats as well.

This raises the naming issue.

html-to-text is a straightforward descriptive name. There is no brand or anything.
It would be natural to seek for a similar descriptive name for the other package.
But there is a well-known issue with npmjs.com - any obvious names are long gone. Some used by other somewhat meaningful packages, many fill the graveyard of unfinished/unmaintained packages.

I've asked an owner of one such dead package if he could transfer the ownership but got no response.

My packages have the same core that governs the processing of input html and other input formats are nowhere on the horizon, while the potential for different output formats had a place in my head for a while and finally happened with a little external stimulus.

I decided I might be able to group my packages under @html-to/ namespace.
(No need to worry, html-to-text is not going away, there would be a long transition and a safe wrapper at the old name in case the transition happens.)

The new package names would look like this:

@html-to/text (same as html-to-text)
@html-to/md
@html-to/html

There is one more issue. I want to publish separate CLI packages. This namespace approach leaves the most obvious package names to be not very pretty:

@html-to/text-cli
@html-to/md-cli

So far, I have no better idea. My current plan is not the prettiest, but I think it is workable. What do you think?

I'm open for other suggestions, in case I'm missing something, or someone has a great brand idea.

If you have better diplomacy skill and can convince the owner of the dead package linked above - that might also solve the issue.

[dargmuesli]

Personally, I think that namespace usage is perfectly fine!

[KillyMXI]

Someone added a comment with valid points here and then deleted it, apparently.

I still want to see these points here and comment on them.

• Using markdown instead of md is more clear.

  Yes, I think @html-to/markdown would work better than @html-to/md. This might need to be solved on a case-by-case basis or the general rule might be to prefer the full name unless it makes no sense completely. No reason to expand @html-to/html. If I decide to add reStructuredText later - that name is rather annoying to type, not sure what is better for that one. If I decide to add Wikitext in some way (it might make no sense, here just as an example) - that name has no associated abbreviation.

• Namespace is better ...

• ... and a generic name instead of @html-to in case you want to build other formatters that don't come from html like text-to-markdown. Examples @text-convert/html-to-markdown and @text-convert/text-to-html.

  I'd go with a different namespace name if there were an idea for a brand name I like. I don't see a different descriptive namespace name I would like. I don't see this project growing outside of html as the source. All improvements I have in mind - revolve around html manipulation. Different input formats would require a completely different processing just to bring them to the common denominator. Current common denominator for all formatters is htmlparser2 DOM AST. Changes that might be required - might make it a completely new project. An alternative to pandoc might be interesting as an idea, but I have no plans and ideas in that direction. And I'm not sure I can make good decisions at this point for something that is so much out of current scope. I think one thing should happen to make it reality - there should be a sponsor who has a good case for it and don't bail out.