Manifest validation needed

[irae]

Making a manifest is hard enough, without validation is super hard for someone not familiar with mendel internals.

For instance, there is a "outlet" requirement on the "bundle". If you don't match exactly with an existing outlet plugin by id you will get an error deep down on inside the compiler chain. Instead we should warn at boot of the pipeline.

Al required fields should be there, al folders should exist, all references by ID should validate and all modules should be loaded successfully before we start mendel. I think having validation will pay off in the long run better than having a installation script, since people start projects simple and add stuff as they progress.

[irae]

Very related to #82

[irae]

Ha! I forgot I already knew about this.

I believe the way to go is to recover mendel-postprocess-manifest. It used to be a file inside mendel-browserify and the sorting and validation is still unused files on mendel-development-middleware.

It should be easy to make mendel-outlet-manifest incorporate the architecture and we could instead of forcing to uglify have this done per configuration, opening the architecture to have people use babily if they so prefer instead of uglify.

Either way, it should be easy to have sorting and validation added back because the data structures are still the same. mendel-manifest-uglify being used without changes proves this is the case.

[irae]

closed by #130

[irae]

I reverted PR #130 and we will be working on this again. No harm done as I didn't push this versions to npm yet.

[irae]

Older validation was breaking because we don't support the notion of "external" on the mendel-pipeline right now.

We do support:

• "expose": when a module is included on a bundle but made available to other bundles by a given name

We do not support:

• "external": When I modules is not on a given bundle, but we expect it to be available on a different bundle.

This has the same underlying issue we saw when @muralikr and @anuragdamle decided to shasum in mendel-generator-prune and later decided they would not use "prune" anymore. The reason was: mendel-generator-prune didn't have enough information to avoid compressing IDs on bundles that had external sources.

In "browser-pack" or in browserify land we used to mark externals with "boolean false" which is different from undefined or something else:

https://github.com/yahoo/mendel/blob/aca231e37b1f56fed5dd14a5ec969eb7830868b8/packages/mendel-manifest-extract-bundles/manifest-extract.js#L102

This was easy to miss when moving to mendel v3. I think it is likelly we need to have our own way of conveying "externality" of deps.

[irae]

And the validation counterpart:

https://github.com/yahoo/mendel/blob/aca231e37b1f56fed5dd14a5ec969eb7830868b8/packages/mendel-development/validate-manifest.js#L37