Zero-configuration application bootstrap and development
278
stars
8
forks
source link
"rave.missing" and "rave.overrides" properties should override package.json and bower.json metadata, not override rave's internal representation of the metadata #50
At the moment, "rave.missing" and "rave.overrides" properties in package.json and bower.json will override rave's internal, optimized representation of the metadata. Since rave's internal, optimized copy is slightly different, there are a few potential problems:
a) it's surprising and confusing to developers
b) user's will have to learn rave's internals
c) users cannot override metadata that rave dsn't care about
For instance, devs can override the default location for myPackage's modules by specifying "rave.overrides.myPackage.location":
However, "location" isn't a valid npm or bower metadata property. npm declares that "directories.lib" is the proper property, but bower provides no notion of directories in bower.json.
I am proposing that we extract the code that maps actual metadata to rave's internal, optimized metadata out of the crawler code. Then, we should process the metadata in the following order:
crawl
override
optimize
Unfortunately, this isn't a complete solution. We still need to allow devs to override properties that don't exist. For instance, "directories.lib" does not exist in bower and "moduleType" does not exist in npm. For these, I propose that we use whatever de facto standard may exist, borrowing properties from the other package manager, if there is no de facto standard.
At the moment, "rave.missing" and "rave.overrides" properties in package.json and bower.json will override rave's internal, optimized representation of the metadata. Since rave's internal, optimized copy is slightly different, there are a few potential problems:
a) it's surprising and confusing to developers b) user's will have to learn rave's internals c) users cannot override metadata that rave dsn't care about
For instance, devs can override the default location for myPackage's modules by specifying "rave.overrides.myPackage.location":
However, "location" isn't a valid npm or bower metadata property. npm declares that "directories.lib" is the proper property, but bower provides no notion of directories in bower.json.
I am proposing that we extract the code that maps actual metadata to rave's internal, optimized metadata out of the crawler code. Then, we should process the metadata in the following order:
Unfortunately, this isn't a complete solution. We still need to allow devs to override properties that don't exist. For instance, "directories.lib" does not exist in bower and "moduleType" does not exist in npm. For these, I propose that we use whatever de facto standard may exist, borrowing properties from the other package manager, if there is no de facto standard.