-
Notifications
You must be signed in to change notification settings - Fork 98
Mention "bad practise" approach #75
Comments
By that i mean "importing" the whole library (at least it is perceived that way) instead of one desired method, complicates understanding what methods is used from library and possible update to new tools in which this plugin wouldn't need to be used. All and all such code doesn't look obvious to me, what do you think? |
This plugin will transform code like: import _ from 'lodash';
_.map([1, 2, 3], addOne); as well as code like: import { map } from 'lodash';
map([1, 2, 3], addOne); Webpack2 and rollup do not support tree-shaking with Lodash. |
Should this be mentioned in the docs? Do you have a relevant links?
I know, but this is not what i asked |
Folks tend to figure it out when they use them. There are open? issues on both I believe. Though the gist of the threads are shrug since both tree-shaking implementations are way too sensitive to potential side-effects, of which Lodash has none. Neither have seemed interested in addressing support for Lodash, so we've deferred to this plugin.
Lodash is pretty hands off when it comes to telling folks how to code. That's why we support both styles. |
I guess you mean webpack/webpack#1750 and rollup/rollup#45? I would add those links to readme, like "If you use rollup or webpack 2 this dependency will be no longer needed after following issues will be resolved - ..."
I would be interested to hear how would you do this, not as recommendation, but your personal opinion, sorry if this out of the scope a bit |
I've gotten the impression that those issues won't likely be resolved. |
Do i understand this correctly - such plugin should be used only if consumer doesn't use tools like rollup or webpack 2 where tree-shaking algorithm is implemented? If so, should this note be added to the docs?
Also, would you agree that this code -
Is worse then
?
The text was updated successfully, but these errors were encountered: