Is it possible to control which "Asset References" mechanisms are active?

[John Reilly]

Hi Guys,

This is probably a slightly niche concern and I suspect the answer is "no".  That said, if you don't ask then you don't get. I'm a big fan of the "Asset References" functionality of Cassette for serving JavaScript files in the correct order.  ( http://getcassette.net/documentation/v1/AssetReferences )

However, for a number of reasons I've taken the choice to never use the Visual Studio XML reference comments like this:

/// <reference path="other.js" />

And rather always use reference comments like this instead:

// @reference other.js

My main reason for taking this choice was because as well as referencing individual JavaScript files I also reference bundles.  Using  Visual Studio XML reference comments for bundles appears to break JavaScript intellisense in Visual Studio 2012.  And I like intellisense.

However, I'm currently investigating using TypeScript to add a little more robustness to my client side code.  And unfortunately I'm falling at the first hurdle.  I was planning to include my JavaScript references within my TypeScript files and keep them around through use of the "not exclude comments" flag in the TypeScript compiler.  Fine and dandy.  However, TypeScript also includes it's "typings" files in the exported comments.  So things like this show up and cause the typings files to be included by Cassette:

/// <reference path="jquery.d.ts" />

Arguably this is a bug in the TypeScript compiler and accordingly I've logged this with the TypeScript team here:

http://typescript.codeplex.com/workitem/995

However, I don't know if this will be addressed anytime soon and so whilst I'm waiting I thought I'd check to see if it is possible to control which "Asset References" mechanisms are active in Cassette?  It'd be nice (for me) if I could just turn off the Visual Studio XML reference comments.  I don't know if that's possible.

If not then I may investigate having a subsequent step in my bundling where I go through and purging references from my TypeScript generated JavaScript file bundles where references that end ".d.ts".  I'm guessing that would work as a fallback - though I haven't investigated yet...  Kind of hoping I don't need to :-)

[Andrew Davey]

You can replace Cassette's reference parser with your own implementation. Unfortunately some of Cassette's parser stuff is internal right now, so you may need to copy-paste the code instead of inheriting.

Implement a IBundleProcessor<ScriptBundle> that scans for only "@reference" comments in each asset and adds references.

e.g.

public class CustomParseReferences : IBundleProcessor<ScriptBundle>

{


    public void Process(T bundle)

    {


        foreach (var asset in bundle.Assets)

        {


            ParseAssetReferences(asset);
            // Makes calls to asset.AddReference(reference.Path, reference.LineNumber);

        }


    }
}

Read all of this http://getcassette.net/documentation/v2/bundle-pipelines to see how to then globally modify all script bundle pipelines. So you can then remove the existing ParseJavaScriptReferences step from the pipeline and replace with your own implementation.

I hope that helps :)

--
You received this message because you are subscribed to the Google Groups "Cassette" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cassette+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[John Reilly]

Thanks for that Andrew - I'll take a look!

[John Reilly]

Hi Andrew,  

I came up with something quite nice for this after a little experimentation.  It required a tweak of ParseReferences.cs which I've sent you a pull request on:  https://github.com/andrewdavey/cassette/pull/382

Thanks for giving me the background and getting me started.

Cheers,

john

[Andrew Davey]

Many thanks, John! I really appreciate this.

I've got a growing queue of pull requests to look at. I hope to get sometime this weekend to check them out.

[John Reilly]

Smashing!