Joe Lencioni
Joe Lencioni
I think it would be good to write some unit tests for findMatchingFiles.js and findJsModulesFor.js before adding this feature.
@trotzig I think this is going to be useful for a bunch of packages still, particularly component bundle packages like [material-ui](https://github.com/callemall/material-ui). Once tree-shaking becomes more mainstream it might not matter...
> By "bloating bundle sizes", I take it you mean webpack bundles for instance? Yeah, or browserify bundles or whatever build tool you are using that doesn't do tree-shaking. If...
Yeah I don't think I've ever seen it actually used. But, using it might give people a reason to add it.
As for `allowInternalModulesFor`, it might be important to specify specific sub-trees to look in, e.g. a build directory or something like that.
includes is interesting, but how do you know which has precedence, includes or excludes? Would it be whichever has higher specificity?
I've given this some more thought. Two things come to mind: 1. If we fast forward a year or two, as tree-shaking becomes more prevalent, I would expect to see...
> It's a code smell if "node_modules" has to appear anywhere. Yes, I agree with this. I think the patterns in this config should understand `foo/bar` as `./node_modules/foo/bar`. > If...
I wonder if this should be combined with #107 and just allow this to be defined in the project's package.json.
We should do this before 2.0.0, so I've added this to the 2.0.0 milestone.