Support Node, Browsers, WebWorkers, & ReactNative about cuid

[gmaclennan]

Do you know what kind of problem keeping different versions has been? The adhoc browser field spec in package.json I think is supported by both browserify and webpack. I think for browsers the issue with feature detection is extra package size, and you would need a special build anyway to ignore node specific modules (e.g. the node version does require('os'). I think the build scripts and code organization can be simplified however, and can take a look at this when I have spare moments.

[ericelliott]

I see the newer code is written in ES2016 and is transformed with babel. I see no need for this for a module like this, it just increases the barrier for contributors, adds an additional build step, and increases code size. Any preferences here? Happy to stay in ES2016 too if preferred.

This module is small/simple enough that ES5 + node-style modules is fine.

IE >= 9 + all major current browsers (including mobile Safari) is fine.

[ericelliott]

Fair point. I'm not actually picky about whether or not there are separate builds. Just that we support everything that needs supporting. Ideally, we can find entropy sources that work everywhere, but that shouldn't be a strict requirement.

[gmaclennan]

Sorry to keep questioning: seeing if I can help clean this up / modernize in the best way. Re. linting / code style, the older source files used a different code style and lint settings that the new files. I see from #31 that you prefer custom eslint over standard. I should format the code to match the current .eslintrc in master right?

I see the newer code is written in ES2016 and is transformed with babel. I see no need for this for a module like this, it just increases the barrier for contributors, adds an additional build step, and increases code size. Any preferences here? Happy to stay in ES2016 too if preferred.

Finally what browser versions should this target? I see the latest .zuul.yml targets IE >= 9, which would be great. IE 8 compatibility could add some overhead, although could be left for the user to do with polyfills. (e.g., using Object.keys(window) as a much simpler technique in browser-fingerprint)