Consider deprecating in favour of "table" package
gajus opened this issue · comments
I have implemented all the previously suggested ideas into a package table.
https://github.com/gajus/table
This package fixes some of the issues with ascii-table too, e.g. support for ANSI escape codes and fullwidth characters. In addition, new features added such as minWidth and maxWidth properties.
Consider deprecating ascii-table in favour of table package.
Cool. I would have suggested to just use https://github.com/Automattic/cli-table instead of making a new project, but hey, now its all fancy and ES6 :)
Seems like it would have been less work to make the changes to this project and create a pull request, not sure if its just the difference in project setup or what. I will consider deprecation, but am going to have to review your project and weigh the LoE in updating this one.
@gajus by the way awesome package name grab! I can't believe that wasn't taken :D
The reason I choose to write a library from the ground up is because I am building something that will heavily rely on text tables and neither of the implementations (ascii-table, cli-table or text-table) met my requirements. I have looked at all the source codes. ascii-table package had the best API, but I did not feel comfortable working with a codebase using prototype inheritance, no separation of logic and minimal test coverage. The other libraries are even more minimal.
I have put a lot of thinking into how to make table package modular, easy to test, easy to contribute to and easy to extend for different use cases.
Sounds like the same reasons I made this module in the first place. I agree with you about the test coverage and the logic separation for the most part, it has been a few years since I've made this relatively unused project, could definitely use some grooming.
Not quite sure what you mean about the prototype inheritance part, its a prototypal language. I think it makes sense to create a class instance that holds the data and can be modified. The table is something that has context and as such can't be purely functional, in my opinion.
I look forward to progress on your project, hope it turns out to be the one table to rule them all! :D
Not quite sure what you mean about the prototype inheritance part, its a prototypal language. I think it makes sense to create a class instance that holds the data and can be modified. The table is something that has context and as such can't be purely functional, in my opinion.
I did not say thats a bad thing. I just don't feel comfortable working with prototypal inheritance.
I look forward to progress on your project, hope it turns out to be the one table to rule them all! :D
Thank you
I am going to mark this as closed since this has been resolve by yourself via another module.