https://discord.umbraco.com
Join Discord
JS only Umbraco V14 Package ?!
# package-development
w
OK I have a JS clientside only package, but for it to be installable as such it needs to be an RCL Nuget Package. So with an RCL does it build a DLL that has the files in it, if I understand correctly ? Or is there a better way to ship a clientside only package to be installed and discverable on the marketplace?
Here is my Nuget package build output, but my knowledge of RCLs is not fab. So is the DLL necessary? If it has the files to copy from staticwebassets and the build/...staticwebassests.props file as well? https://cdn.discordapp.com/attachments/1240274378353152052/1240277739634823309/image.png?ex=6645fa28&is=6644a8a8&hm=06eaf9d3ff75caeabfc85074c92f780e2ef70772c4aff87087c95a4171b0b674&
@Kevin Jump I suspect you may know...
k
Hi, the DLL doesn't have anything in it (unless you also have razor views). the static assets folder is just that a folder.
you can tell the csproj not to include the dll (i think) but its not really an issue to have a basically empty one
infact it can be good because if you have some c# code in the rcl, then it will tie the .net version required for the package (e.g .net 8) so that can help / stop people accidently installing the package on an incorrect version
w
Yeh the CSProj has no C# or Razor views
But if its not gonna hurt to have it either then suppose will leave it in then
And my package has a nuget dependancy on V14
Again not that my CSProj needs a dependancy on a V14 only Nuget package...
Would love to know what is the best/good way to ship only clientside packages. Any thoughts from the HQ crew @Jacob Overgaard or anyone else
j
Marketplace only picks up Nuget.org packages for now, so if you want your package to be on there, you need to ship whatever works for nuget.org. Don't know exactly what options you have vis-a-vis static assets. I suppose an RCL is the best choice since your umbraco-package.json file needs to be in a certain path (e.g. app_plugins/package-name) and so an RCL provides you an excellent opportunity to map that up with the staticassetspath config option.
w
Yep OK will go with this approach for now
m
Just out of interest dependency is 
>=14.0.0-rc2
? will that not allow installing on any future version of umbraco? I guess this is tied somehow to 14-rc2.. so presume at somepoint an umbraco version could mean it no longer works? Is it safer to tie to umbraco cadence... at least with an upper boundary of next lts? 
<dependency id="Umbraco.{pacakge}" version="[14.0.0-rc2,17.0.0)" exclude="Build,Analyzers" />
??
still have to double take the nuget syntax for [ is >= and ) is < 🤔
w
Yeh I can do. For now it’s just get it out there is my plan.
s
I think the upper dependency is just an annoyance. At least for 10-13 a lot of packages hasn't needed any changes other than changing the upper dependency. Because of this I only set a lower one. If one installs it in a version that the docs dont state support for, then its their own fault - or a bug in the documentation 🙂
m
@skttl so yeah 
[10.0.0, 14.0.0)
? as you know it's more than likely going to break in 14 as that's linked to the next netcore release?
if it's just down to documentation then what's the point of having that nuget facility? also doesn't the marketplace read the dependencies for what versions of umbraco to list it under? 🤔
Also VS nuget package manager will allow you to install the latest it thinks is supported?
s
more than likely to break in 14 - but no chance to predict that if you were releasing in early 10 time
if a package has an upper dependency on 10, you cant install it in 11, even though I think almost all 10 packages worked out in 11 without changes
m
wasn't close enough to it.. was the roadmap linking to netcore cadence not with umbraco come v10?
and I guess it's either the package developer tests and raises the upper boundary with a release.. or you have your users with broken packages that can be installed but fail?
merit either way.. users clamouring for a release (and overhead) vs users don't have to wait but have a spoonful of doubt
s
As a package consumer, I'd much prefer not having to wait (or bug the developer) about an update. And as a developer, the burden is probably the same whether it's people with broken packages as opposed to people without the ability to install. And historically, packages often just works in the next major
m
as a counterpoint as a package consumer (and assume not a developer) who follows docs such as 
dotnet add package Umbraco.Forms
I'd just like nuget to install the correct package that works for my curent umbraco version (which is what upper and lower nuget dependancies are for??) but interesting to hear all viewpoints... 🫶 love this community!
12 Views
PreviousNext
Powered by

Umbraco

A hub and casual space for you to interact with fellow community members and learn more about Umbraco!

Powered by