jwalton
commented
10 years ago The current behavior is to start at the source file in question, walk up the directory tree until we find package.json, and try to load configration from that file. If configuration is not found, then we will continue to walk up the tree until we find another package.json and will try again. This is similar to how browserify-shim looks for configuration.
There are arguments to be made in favor of this algorithm; when you require a file, this is similar to the algorithm that node uses to go looking for the file you're requiring (walk upward looking for "node_modules", if you fail keep walking upwards.)
Here's where I feel this breaks down, though: Suppose you're using debowerify. One of the weird things you're going to run into is that browserify is going to try to run your transforms on packages it loads from bower, which is the opposite of the behavior for packages it loads from npm (see opts.global.) This means that browserify-transform-tools is going to look in the bower component for configuration first, and then fail up to your project. I think that the majority of the time, though, you wouldn't want any configuration found in the child project to be loaded; that configuration is probably there for building that child project, and probably isn't intended to be run when loading that project. Also, you probably do want your transform configuration to run.
So, I'm going to make the default walk from the cwd and stop at the first package.json it finds. If you want the old behavior, it will be available via a fromSourceFileDir option.
When loading configuration from package.json, we should start at the cwd and look upwards for package.json, instead of starting at the js file we're transforming.