NuGet / Home

Repo for NuGet Client issues
Other
1.5k stars 252 forks source link

Migrating frontend packages to bower #930

Closed Eonasdan closed 6 years ago

Eonasdan commented 9 years ago

I am the author of a Bootstrap DateTime picker plugin. (LESS, CSS). I have (combined) 70,000 downloads with 6,000 of those being in the last month alone.

Many of my users are not aware of the upcoming changes. With Nuget/MVC/Asp.Net moving away from delivering frontend packages like this and expecting people to use bower, it will be a shocking revelation to them when this happens. As such, I'm afraid that I will lose part of my user base--those who may not realize that there's a new/different way to get frontend packages like mine. I think that it is important for Microsoft to make this transition smoother, not only for package managers like myself, but especially for my users.

I propose that an XML node be added to the spec that would allow me as an author to point Nuget to my package on bower. This should also cause Nuget to pull down a bower package instead, for new projects (MVC 6). Perhaps some indication to the user that this happened for them in the background: "Hey you downloaded this fontend package but you should really get it from bower".

This wouldn't need to be a permanent addition; just one that would allow the bandage to fall off rather than being ripped off.

Thanks to @csharpfritz for suggesting that I make this issue.

yishaigalatzer commented 9 years ago

We currently do not plan to make nuget the global package manager, or create such links between nuget packages and other packages sources, I think we will need to come up with something more creative here.

Also note that ASP.NET 5 projects are not currently managed by NuGet directly, so this issue might be a discussion point with the ASP.NET team.

CC @davidfowl @DamianEdwards

Eonasdan commented 9 years ago

I posted this to the .Net team: https://github.com/aspnet/Home/issues/742

I just think there needs to be some intermediate transition. Bootstrap's own Nuget package has 232,490 downloads since March. I'd guess that a large percentage of those downloads have no clue about this until it hits them in the face.

yishaigalatzer commented 9 years ago

I semi agree with you. They will google it, and find out in 2 minutes that they need to move to Bower. Also all the new project templates include it. So its a good thing to improve but not blocking. Although your idea is really supposed to land in the ASP.NET land it has merit for the UWP and project.json in the normal .NET land.

We are discussing your idea, and we think some sort of a notification could be useful.

Here are some strawman level design:

  1. Packages that have install.ps1/uninstall.ps1/content/XDT when using project.json produce a warning.
  2. The user can provide a tag that suppresses the warning if the package is supposed to work properly in both cases.
  3. A user provides a tag that makes the package fail to install if content is not supported.
  4. The user can provide a tag providing a migration path if his package is no longer compatible 4.1 A new package was created to replace the original package/Or he has to move to bower 4.2. Some manual work is required 4.3. Some command needs to run in the powershell console
ljw1004 commented 9 years ago

I hope that Bower isn't adopted as the standard for client apps. I already have to keep track of so many kinds of references - Framework, P2P, SharedProjects, NuGet, ServiceReferences. AnalyzerReferences, ConnectedServices. Please don't add yet another one for functionality that was already working great as part of NuGet! (especially since I'd like my old NuGet content packages to continue working).

I get that ASP and web folks feel comfortable with Bower. Indeed, Bower.io starts with the line "Web sites are made of lots of things".

yishaigalatzer commented 9 years ago

This is about web. But note that Cordova apps are already recommending bower as the way to go for client apps. Nuget was never great at content.

williamsodell commented 9 years ago

Bower has its place, for client side technologies. Even other package mangers for server side code have been recommending against putting client side technologies in their package manger.

I would think it would be best to keep these things separate. I do like the idea to be able to add notifications. Could be good for when someone wants to discontinue a project as well.

yishaigalatzer commented 9 years ago

Notifications are not a bad idea. Would you mind opening a separate issue and layout you idea a bit more?

Eonasdan commented 9 years ago

in the current form (stable) it's easy to add a powershell to open the VS browser or a readme file, but running a ps script is also going away, correct?

yishaigalatzer commented 9 years ago

Yes it is.

yishaigalatzer commented 9 years ago

We just added a feature where in ASP.NET 5, packages that have bower equivalence show a link that takes you to the bower installer directly from NuGet.

It will be available in 3.3, there is no link inside the package (yet), but we could that in a future release.

@madskristensen owns the list of the links (which I believe is package name and source)

Eonasdan commented 9 years ago

sweet! Thanks guys!