v2: Make a decision on casing for the default export

[Brian Grinstead]

TinyColor vs tinycolor:

The lowercase variation is the v1 API, so keeping that would make migration easier. The camel cased variation is more typical for class naming.

This mostly just affects UMD users and how we write it in documentation if we go with something like #181 where we do a default export for node.

[Scott Cooper]

i'm leaning lowercase

[Brian Grinstead]

Yeah, I've gone back and forth. I'm also leaning lowercase for now since that'll make migration from v1 to v2 seamless for most cases. I actually wish it was camel case to match the project name, but I think there's value in uncoupling that potential name change from getting v2 shipped.

[Brian Grinstead]

OK, so if we go this route I guess this means using lowercase name from UMD export (already done) and updating docs to show lowercase code. In theory we could keep all the casing in the implementation as-is since from node / ts it's done with a default export - the class name doesn't really matter as callers pick the variable to import name import tinycolor from './public_api or var tinycolor = require('./public_api');.

Although I have noticed that errors in test files showing up with the camel cased even when the variable is lowercased - i.e.

import tinycolor from '../src/public_api';
tinycolor("red");

throws:

TypeError: Class constructor TinyColor cannot be invoked without 'new'

Which is maybe confusing?

[Brian Grinstead]

We could go through and lowercase the actual class, although ts wouldn't like that.

[Brian Grinstead]

To be clear: I'm not suggesting that tinycolor("red") should actually work in the snippet above - it's just an example of an error message I remember seeing where the casing is out of sync

[Scott Cooper]

i think we should keep it showing new because it is still a class.

I do think some of the readme examples no longer work?

import { fromRatio } from 'tinycolor2';

might not be working anymore.