Updating of references to js libraries.

May 4, 2011 at 3:42 PM

Hi guys.

Hi have an suggestion for a new functionality. Today I was updating jQuery package from previous one to 1.6 and it would be nice if NuGet would update also references to all affected .js files in project. It's just a small #nicetohave feature. :)

Anyway, thanks for great tool.


May 5, 2011 at 2:19 AM

We discussed something along those lines yesterday, and it would indeed be nice to do. The hard part is to do the proper replacement. Blindly replacing all instances of the script file name with the new name is probably a bit too aggressive, so it might take some fancier parsing to do the right thing.

May 5, 2011 at 6:11 AM

Or maybe it would be sufficient to only replace the strings in master page of app using default name of master page file (like _Layout.cshtml in MVC 3 with razor) and replace string in this only one leaving other references to user.

May 5, 2011 at 6:16 AM

That feels maybe a little too conservative. While it would cover the default scenario, users might be puzzled why it doesn't work for their other references to those files.

May 5, 2011 at 6:17 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Jul 12, 2011 at 12:05 AM

I just added a comment to the issue, but wanted to get your thoughts on this: What if we simply output a warning for now when we discover a case where we think you might need to update your script references?

Most web developers will have their script references centralized (for example, using layouts etc) so ideally there's only one place to update the scripts. So updating the scripts is not the painful part. The painful part is knowing which ones need updating.

So we could play it safe and simply issue a warning. There's a couple of heuristics we could try:

1. Simple

If the new package contains a js script (or css file) that's new or non-existent in the previous installed version of the package, output a warning. If this is the first time this package is installed, output a warning for each script/css file.

2. Advanced

Same rules as the Simple case, but scan the project for places where the script/css file is referenced and output a warning with specific information.

Jul 12, 2011 at 12:51 AM

I think a flavor of #1 might be sufficient to keep things simple. Frankly, if we have the smart to do #2, we may as well take it all the way and modify the references. But that can come later.

Couple points/concerns:

  • Why output warnings the first time the package is installed? Presumably, you don't have references to older versions of those files, unless you manually got them from somewhere. I think what's important is not what's new, but what gets removed. i.e. it doesn't matter what new things the new package brings in. What matters is the set of files that were in the old one and not in the new one. 
  • One concern is that warnings are undiscoverable when installing through the UI. I think they show up in the Output window, but I'm not sure we give it the focus.
Jul 12, 2011 at 12:55 AM

Great questions:

  • The scripts being added might be in a package that's a dependency of a package you are installing. For example, suppose you are installing Package A -> Package B -> Package C. You might not be intimately aquainted with every package in the chain. I thought it would be helpful if we told you in effect, "Hey! There's some JavaScript files this package includes that you might need to reference in order for anything to work correctly."
  • Yeah, we probably need to make warnings more prominent in the UI. Perhaps a dialog for "user-actionable" warnings?
Jul 12, 2011 at 1:09 AM

My take is that this would give too many benign warnings. If I bring in some packages that have .js files, I don't need a warning any more than I need one when I bring in an assembly that has some public surface. The warnings should be saved for cases where the NuGet operation might have caused to project to become broken, and that should never happen unless some file that was there before is now gone.

Jul 12, 2011 at 6:27 AM
Good point. My mind is changed. I agree. :)