bazaarvoice/static-asset-service

An optimization service for web application static assets.

static-asset-service's Issues

Add link to original gist, or copy gist to docs

We were looking for this earlier, figured it may be beneficial so let's add a link to it somewhere in this repo or just move it:

https://gist.github.com/rmurphey/6842b3b1b806dd123676

Update for new static asset loader client model

Currently the static asset loader client in bv-ui-core (https://github.com/bazaarvoice/bv-ui-core/tree/master/lib/staticAssetLoader) is dumb: it doesn't understand dependencies, and doesn't want assets using the old define(name, dependencies, asset) signature. The idea here is that clients explicitly state all dependencies they require, and the list is winnowed prior to any request being sent given what is already available.

The generator does need to understand dependencies because asset packages are named / required in alphanumeric order - [email protected][email protected] regardless of the order they should be loaded in because of dependencies.

So the present code needs some work. I propose:

• a metadata JSON file per asset to include dependency information.
• the generator uses that information to order and arrange the contents of the generated files.

It is an open question as to whether the generator should include unrequested dependencies. I'm inclined to think it should not based on the present model for the client, which is to require everything you want in one lump, and that gets whittled down prior to the request being made. If the objective is to suppress the loading of assets twice, then including dependencies not explicitly required seems the wrong way to go.

Deploy to prod

Firebird is finally ready to start using the static asset service.
However, we'll need the static assets deployed to prod before we can release it.

Are we ready to deploy these files to prod ?

Move SDK to bv-ui-core

The SDK (https://github.com/bazaarvoice/static-asset-service/blob/master/sdk/index.js) of this could very likely have value beyond BV, and has no secret sauce -- it is essentially Yet Another Script Loader, created for the specific purpose of sharing vendor files across applications on the same page. Putting it in bv-ui-core would make it even more trivial for third-party JS applications at BV to include the SDK in their scout file.

Per discussion with @reason-bv, we should take the SDK, extract the BV-specific pieces, and ship it with the rest of bv-ui-core. This would also allow us to make the dependency on the JS loader in bv-ui-core more explicit than it is now.

Finally, this would require some minor documentation additions, such as explaining how to create a file that can be used by the static asset service.

Generated files are not namespace wrapped when uglify is set to false.

When the uglify flag is set to false, the generated assets do not contain the function wrapper that defines define.

Deployment should not fail if sourcemaps aren't present

In the case where assets are not minified, no sourcemaps will be present in the destination directory. Currently, the deployment task throws an error if there are no sourcemaps which makes it impossible to deploy an unminified asset.