Closed alexisvincent closed 7 years ago
After a little bit of thought, I think that all that needs to happen would be to add a filter
key to the fined
config option. This would mean, when it discovers a file, it could pass the file path to the provided filter
function. If the function returns true
it is assumed to be the config file, and on false
it moves on.
This would mean folks could do their own package.json
checking and is a good general solution.
I believe you can already implement that with the https://github.com/js-cli/js-liftoff#optsconfigfiles feature that @sttk added. It would only require a little glue-code in your implementation. Right @sttk?
@phated Thanks for the response. But after reading the docs, I don't see how I would implement it.
You define package.json
as a config file that you want to "find" and then you require
it and pluck the property you want to use.
Oh I see, I was under the impression that it stopped once it found a file, but if it returns all the config files that conform to the rule that's diffirent
:+1: to that. Also, Liftoff automatically provides the value of package.json
for you under the modulePackage
key. If you don't need a "non-standard" lookup path, you can use that. For example:
https://github.com/js-cli/js-hacker/blob/master/bin/hacker.js#L43
@phated Yes. But as @tkellen says, the full path and contents of package.json
are already given as env.modulePath
and env.modulePackage
. It's easiler to use them.
Thanks @tkellen and @sttk! I'm going to close this.
Hey guys,
Great project :) Does pretty much everything I do manually and more.
The only thing that I currently do that I wouldn't be able to with this project is, check for a specified key in the
package.json
and use the object it maps to as config (if it exists). Similar to what babel does.So for instance. I can config my cli utility either through a
systemjs-tools.js
file or asystemjs-tools
key in package.json.What would it take to support this?