Skip to content

0.2.0: Compatibility with many more bower and npm packages

Choose a tag to compare

View all tags
@unscriptable unscriptable released this 11 Jul 14:56
0.2.0
7f3ee54

What's new

  • Third parties can provide missing metadata values
  • Third parties can override metadata values
  • Module type can be determined at run time as a last resort
  • Bower metadata crawling is more robust
  • The de facto "browser" field in package.json is now supported
  • Miscellaneous code and documentation problems are fixed

Third parties can provide missing metadata values, a.k.a. "rave.missing"

Third-party rave extensions can now provide default values for bower or npm packages that are missing bower.json or package.json properties. This feature, "rave.missing", isn't documented, yet. It can also be applied from the application's top-level bower.json and package.json files.

Third parties can override metadata values, a.k.a. "rave.overrides"

Third-party rave extensions can now override values for bower or npm packages that have erroneous bower.json or package.json properties. This feature, "rave.overrides", isn't documented, yet. It can also be applied from the application's top-level bower.json and package.json files.

Module type can be determined at run time as a last resort

During development when moduleType is not specified for a package, rave now uses fewer heuristics to determine moduleType and instead scans the first module in a package to determine the moduleType. Scanning is expensive, of course, but won't happen in production and can be eliminated with the new "rave.missing" feature (above). Some rave extensions will break due to this change. (Thus the version bump to 0.2.0.)

Bower metadata crawling is more robust

Bower metadata crawling is now more robust (thanks @KidkArolis). Now, the bower crawler will look for bower.json and package.json. Failing to find those, it will create a minimal metadata descriptor that should satisfy the majority of packages that didn't supply metadata. When used in conjunction with moduleType scanning (above), we should be able to correctly guess the correct metadata for the vast majority of bower packages now.

The de facto "browser" field in package.json is now supported

@KidkArolis added support for "browser" field in package.json. When the "browser" field is present in package.json, its values are processed as per the widely supported unofficial spec. This allows package authors to specify different modules to be loaded in the browser, rather than in node. There's a hidden gem in here: @KidkArolis added generic module name mapping as part of this feature. We could leverage this feature in other ways.

Assets 2
Loading