Thanks for the feedback! Improving the documentation is definitely one of my priorities, but I hadn't thought of documenting the overall structure. Do you have any suggestions for how best to do that?
"The source code is in `index.js`. In order to build the minified version, run `[command]`. [description of what `index.js.min` is, and how it compares to `dist/ac-colors-min.js`] [Maybe short description of other travis commands used during development]"
Basically, imagine you're running into this repo having never looked at it before. What do you want to know?
From there, you can go one level deeper, and document `index.js`. It's not rocket science, but it is helpful. For example, I have no idea what `256colors.js` is, or how it's used for testing. That should be either a comment at the top of the file, or in the README (depending on how important the file is).
When you go into `index.js`, it's nice to have an overview of what's what in the file, and how it's structured. I like when docs are build from files, actually (so instead of all of this in `README.md`, you have that in comments in code, and build to something like `README.md`). I also like having clearly documented inputs and outputs.
I also really recommend blank lines between functions. This is especially true if you have blank lines within functions. lchabString, lchab, and the first part of rgbtoHsl fuse into one big code paragraph right now.
I wouldn't necessarily take what I say as how you ought to do it -- that's a question of style, and how I solve these problems. Take it more as a problem statement and example solution.