saaskit
saaskit copied to clipboard
denoland
suggestion: `deno task update` and automatic updates
An update task like this would be fantastic. This'd also be great to integrate into a weekly GitHub action like this to keep dependencies up-to-date.
I would have to dig a bit to understand how this works, but that action looks like a good idea. Until GitHub's dependabot don't understand Deno natively this should be a good idea to implement.
I would like to grab this in the next couple days. Will be at KubeCon next week. So if someone else wants to grab this, go for it :)
Actually, it'd be best to have decent test coverage before proceeding with this feature. Otherwise, bugs caused by updated dependencies could fall through the cracks.
We're ready to pursue this. All Fresh dependencies (those that come along with Fresh) should only be updated manually.
I started working on it. One thing that we have to discuss is the case of the semantic versioning and what kind of versions we would like to see. Because right now without any version flags for udd I will get preact in version 11, which is, as of this writing, in experimental mode. I don't think that we would like to directly update to those versions.
However, do we like to see those changes anyway or maybe also have two task definitions, one checking for "production" dependency updates and one for "experimental/major bumps"?
Following are some output examples. The first is without any restrictions on the dependencies, which in my opinion is a little risky to use.
Already latest version:
https://deno.land/x/[email protected]/ == 1.2.0
https://deno.land/x/[email protected]/mod.ts == 0.2.3
https://deno.land/x/[email protected]/ == 0.2.2
https://deno.land/x/[email protected]/mod.ts == v0.2.5
https://esm.sh/*@preact/[email protected] == preact
https://esm.sh/*@preact/[email protected] == preact
https://esm.sh/[email protected] == 4.2.2
Able to update:
https://deno.land/[email protected]/ 0.188.0 -> 0.192.0
https://esm.sh/@twind/[email protected]/ 1.1.4 -> 2.0.0-next-20221213150400
https://esm.sh/@twind/[email protected] 1.1.3 -> 1.2.0-next-20221226213230
https://esm.sh/[email protected] 10.15.1 -> 11.0.0-experimental.1
https://esm.sh/[email protected]/ 10.15.1 -> 11.0.0-experimental.1
https://esm.sh/*[email protected] 6.1.0 -> undefined
https://esm.sh/@twind/[email protected]/ 1.1.4 -> 2.0.0-next-20221213150400
https://esm.sh/@twind/[email protected] 1.1.3 -> 1.2.0-next-20221226213230
With every dependency set to ^ we'll get:
Already latest version:
https://deno.land/x/[email protected]/ == 1.2.0
https://deno.land/x/[email protected]/mod.ts#^ == 0.2.3
https://deno.land/[email protected]#^/ == 0.188.0#^
https://deno.land/x/[email protected]#^/ == 0.2.2#^
https://deno.land/x/[email protected]/mod.ts#^ == v0.2.5
https://esm.sh/@twind/[email protected]#^/ == 1.1.4#^
https://esm.sh/@twind/[email protected]#^ == 1.1.3#^
https://esm.sh/[email protected]#^ == 10.15.1#^
https://esm.sh/[email protected]#^/ == 10.15.1#^
https://esm.sh/*[email protected]#^ == 6.1.0#^
https://esm.sh/*@preact/[email protected]#^ == preact
https://esm.sh/*@preact/[email protected]#^ == preact
https://esm.sh/@twind/[email protected]#^/ == 1.1.4#^
https://esm.sh/[email protected]#^ == 4.2.2#^
https://esm.sh/@twind/[email protected]#^ == 1.1.3#^
As you can see here std is not updated. This is because udd skips those when the major version is 0.
Removing those with a major version < 1 gives us the following:
Already latest version:
https://deno.land/x/[email protected]/ == 1.2.0
https://deno.land/x/[email protected]/mod.ts == 0.2.3
https://deno.land/x/[email protected]/ == 0.2.2
https://deno.land/x/[email protected]/mod.ts == v0.2.5
https://esm.sh/@twind/[email protected]#^/ == 1.1.4#^
https://esm.sh/@twind/[email protected]#^ == 1.1.3#^
https://esm.sh/[email protected]#^ == 10.15.1#^
https://esm.sh/[email protected]#^/ == 10.15.1#^
https://esm.sh/*[email protected]#^ == 6.1.0#^
https://esm.sh/*@preact/[email protected]#^ == preact
https://esm.sh/*@preact/[email protected]#^ == preact
https://esm.sh/@twind/[email protected]#^/ == 1.1.4#^
https://esm.sh/[email protected]#^ == 4.2.2#^
https://esm.sh/@twind/[email protected]#^ == 1.1.3#^
Able to update:
https://deno.land/[email protected]/ 0.188.0 -> 0.192.0
Which is in my opinion a better choice. What do you think?
Another issue I found is running deno task ok or deno task start fails with errors. An example is :
error: The specifier ""preact/hooks"" backtracks above its prefix ""preact/""
at https://deno.land/x/[email protected]/src/runtime/csp.ts:2:28
This is happens when I set preact to the current major version like:
"preact": "https://esm.sh/[email protected]#^",
"preact/": "https://esm.sh/[email protected]#^/",
Yes, the 2nd option looks better. It's pretty much what I was talking about in my previous comment - better said, version pinning.
If pinning versions causes issues for cases like preact, then that's a dealbreaker. Our options would be to use a different dependency updater or contribute to udd, which, frankly, doesn't appear to be actively maintained. WDYT?
Hmm, not being able to start the app with pinned versions really is a dealbreaker. Do you know about different dependency updater before we dive deeper into udd and maybe start contributing to it? For now I would not use the current version of udd when that means that we have to check for every dependency if version pinning is usable.
I mean the pinning only crashes for dependencies when they're used with a / at the end such as preact and preact/ but still, this is one of our main dependencies.
Let us have a look if we find other (maintained) dependency updaters. Otherwise I would suggest diving deeper into udd to see if we can fix that version pinning issue.
