git checkout <branch> causes multiple bundle popups when JS files are autogenerated

[jt000]

I have a project that auto-generates JS files during the build, which are included in a web essentials bundle. Whenever I change my git branch or clean my folder Web Essentials starts popping up all sorts of error messages. It'd be great if there was a way to disable bundle on save and only have bundle on build for this particular bundle (maybe a <runOnSave>false</runOnSave> option in the bundle file?).

[am11]

Nice idea! 👍

But can you expand on:

... Web Essentials starts popping up all sorts of error messages.

what kind of error messages?

Currently, WE uses .NET's FileSystemWatcher to watch bundle's constituent files (see http://vswebessentials.com/features/bundling). If you delete the CSS files for instance and expect it to reattach watcher (for defer generation of those documents from superset languages), then we don't have that ability yet. If don't know if FileSystemWatcher do it internally or not? Apparently the file handle is lost once the file is deleted and re-spawned (dangling pointer thingy)?

If there is a viable demand for this feature, then it's worth taking a stab at. This would be fun coding though. And to know that, we have a uservoice channel in place: http://webessentials.uservoice.com/. Let's post the idea there and see the community's reaction! :)

[jt000]

The error messages are the file missing popups. When I do a "git checkout " or do a clean (which deletes all the auto-generated JS files), then I'll get a popup for every file that's in my bundle that says something like "foo.js not found". In my case, its about 25 popups that I have to close every time I do a branch change in git.

I'm not sure uservoice is right for this issue. I titled this like a feature request, but the underlying issue is the massive amounts of popups I get whenever I do a branch change in git. One possible solution is to introduce a runonsave property that would ignore any FileSystemWatcher events, but if there's another resolution to the popup issue, then I wouldn't be opposed.

Another simpler alternative might be to output the error in the output window rather than in a popup. (I updated the title to clarify the issue)

[am11]

True; that popup is really nagging. I think it's a brilliant idea to send those messages to output window. @SLaks, @madskristensen thoughts?

Or we can implement an aggregated popup (like when closing VS with multiple unsaved documents). For that matter, we would have to build some extra machinery for it; to first confine the transaction task in asynchronous environment and prevent it from overlapping with other operation's notifications. It is also affecting other scenarios. See this discussion: #284. (we haven't tried @SLaks' method yet, but it is an interesting and challenging task and reasonable from UX perspective)

[madskristensen]

output window sounds good, cheap and low risk

[am11]

Cool!

BTW, I think @jt000 will still be facing "bundle not updating" issue, since the observer would be detached (and we would have to figure out a way to reattach it when the CSS/JS files are re-generated by superset langs). See

WebEssentials2013/EditorExtensions/Misc/Bundles/BundleFilesObserver.cs

Line 148 in f1b7099

//Well, if the file doesn't exists anymore, there is no use for this observer.

.

First, let's send the error messages to output window.. :)

[jt000]

Thanks @am11 & @madskristensen. I haven't seen the "bundle not updating" issue occurring. "runOnBuild" is set to 'true' on my bundle, so if its not bundling on save it shouldn't be an issue for me.

[am11]

Actually that is a different use-case (it will not give you error, you would have to observer it):

"When the user opens a solution in VS, WE starts watching all bundle files including their constituents. If you make any change in bundle or constituent file, the bundle is rebuild. In this case, that interval; where you haven't built the solution yet, any change in the constituent file will not trigger the bundle rebuild."

[am11]

@jt000, can you confirm if nightly build v2.3.4.1 fixes this issue and there is no further issue (like the one mentioned in previous comment)?

If it is working, this issue can be closed as resolved.

[jt000]

Sorry, just saw this was merged. Yes, I can confirm that I'm no longer seeing the popups.Thanks @am11!