One way to manage running deno scripts on different deno versions across different systems could be to add a --version-constraint arg to deno run that is checked before the script is run.
That way we could add this to a shebang to denote this script requires a specific/range of local deno versions.
Something like #!/bin/env -S deno run --version-constraint ">=0.5.0" --allow-all to denote that this script requires a deno version bigger then 0.5.0 etc.
Just some thoughts, wondering if it makes any sense to add this.
dnorth
Why wouldn't you just express this in the code itself. You would be able to handle it more gracefully there as well. I am not sure what problem it solves by adding it on the command line.
@kitsonk
Because literally the code wouldn't compile if the API of the Deno superglobal changes, no?
Hmmm... I guess there you would have your Deno version check implicitly right there, I guess users just wouldn't know explicitly what version of deno to get?
The argument in a shebang would make it explicit what version to get and also not have the user try to think its a bug or so?
Like the check at runtime wont even be reached when the ts compilation fails, so your error log will likely say something cryptic-ish about: there's no method Deno.oldFunction, so I'm sure some users will instead just do a bug report and think there's nothing to be done.
Another problem is that adding this argument wouldn't be able to track deno version-constraints per library either, but just for the main entry point rather.
Still I suspect this could be useful?
@davidjamesstone your idea is probably useful, but as @kitsonk suggested you can do it inside your code using Deno.version:
console.log(Deno.version);
// { deno: "0.6.0", v8: "7.6.53", typescript: "3.4.1" }
Special CLI flag for that seems magical.
@bartlomieju I don't think you can do this because if you depend on a library that uses a Deno API that has changed or disappeared your code won't even compile.
Your code will never be run, no?
@bartlomieju I don't think you can do this because if you depend on a library that uses a Deno API that has changed or disappeared your code won't even compile.
Your code will never be run, no?
This case will not appear once the deno will be released. After deprecation will be used.
@bartlomieju I don't think you can do this because if you depend on a library that uses a Deno API that has changed or disappeared your code won't even compile.
I that case solution with CLI flag --version-constraint won't be of any help.
@zekth but deprecation would still lead to removal eventually no? so this still will be a thing?
@bartlomieju what do you mean it wont be of any help, I have outlined above how it would be of help - it would explicitly tell the user that the issue is that he has the wrong deno version and the version constraint could be shown to direct him towards a compatible version, instead of showing him cryptic "can't find Deno.oldMethod" and compilation stops.
Why wouldn't it just be a comment in the script file then. Passing it to Deno does nothing. What would you do if the version was incorrect? Log out an error and not run the code? That would be the same as not running the code. Also the author would assume that Deno would always be forward compatible for all the APIs the use, only for initial command line scripts. Not very logical, or useful.
We have a lot of API churn and breaking changes right now, but this feature would not benefit users IMO and likely cause issues where there aren't any. The internet is littered with code that does UA sniffing, assuming it knows what is going on.
Maybe we need a function which is looks like function canIUse(name: string): boolean to check something we want to use.
Deno is unstable. We're not going to add code to work around that fact. Over time it will become more stable.
Most helpful comment
Why wouldn't you just express this in the code itself. You would be able to handle it more gracefully there as well. I am not sure what problem it solves by adding it on the command line.