@1.2.0 increases build size 40 times

[alekseykulikov]

21 increases browserify build in 40 times, because of Buffer keyword usage. It makes this library useless for small browser components, which was an original purpose.

$ npm i component-type@1.1.0
component-type@1.1.0 node_modules/component-type
$ browserify node_modules/component-type | wc -c | pretty-bytes
1.23 kB

$ npm i component-type@1.2.0
component-type@1.2.0 node_modules/component-type
$ browserify node_modules/component-type | wc -c | pretty-bytes
50.55 kB

$ npm i underscore
underscore@1.8.3 node_modules/underscore
$ browserify node_modules/underscore | wc -c | pretty-bytes
53.42 kB

I'd suggest to revert buffer check and release it as 2.0.0. We have Buffer.isBuffer, but we don't have normal typeof.

[dy]

@alekseykulikov technically it is able to use --bare or --no-builtils flag for browserify to avoid size bloat. For small components, btw, it might be a good practice to use per-type checkers, like is-array, is-fn, mutype, 101 etc, as far types are tightly bound to the environment.

[alekseykulikov]

@dfcreative

technically it is able to use --bare or --no-builtils flag for browserify to avoid size bloat

yes, but I usually don't compile component-type separately, and in the app bundle this flags won't work

it might be a good practice to use per-type checkers, like is-array, is-fn, mutype, 101 etc, as far types are tightly bound to the environment.

yes, it's useful, when you need to check only one type, but when your library checks multiple types, it's convenient to require type once.

[juliangruber]

a real world browserify project is very likely to reference Buffer at some point, does yours not?

[alekseykulikov]

It depends on functionality scope, for example simple login/signup pages most likely won't use Buffer, SPA probably will. But for front-end libraries, it's a different story. For example treo relies on component-type, and full standalone build is just 18kb. If I use component-type with semver's ^ it's unexpectedly became bigger on 50kb.

[juliangruber]

i'm quite sure we can come up with a check for buffer type that doesn't require('buffer'), for example calling https://github.com/feross/buffer/blob/master/index.js#L433

[alekseykulikov]

Agreed with @juliangruber, we can use something like:

if (val && val.inspect == 'function' && val.inspect().indexOf('<Buffer') === 0)  return 'buffer';

[dy]

Calling the inspect doesn’t seem like a nice way to check the type, in terms of performance. There is a ready solution for checking the buffer type: is-buffer, which seems to be better than duck typing). We can delegate work to that package, it is tiny and reliable.

[juliangruber]

@dfcreative that module looks perfect, now someone just needs to submit a pull request

[juliangruber]

well and someone needs to port it to components

[chemzqm]

It's quite annoying to have this little library build with buffer shim, so I made the changes. Still need someone help to publish it to npm, as I don't have the right to do so @juliangruber
Just run npm publish would be fine, the test file is also fixed This also resolve the problem with #23