Devise a way to lock the version of jk when generating configuration

[dlespiau]

@palemtnrider made the comment that, if the goal is to always generate the same output for the same input script, it'd be a good idea to also ensure everyone (all developers but also CI, a potential future flux hook, ...) is running the same version of jk.

I was thinking we should support reading a .jkcfg config file in the current working directly where we could source options from instead of having them on the command line. That file could also hold the required jk version and jk could bail out if the its version doesn't match the specified version, eg.:

requiredVersion: 0.2.5
entrypoint: config.js
...

[errordeveloper]

Doesn't package.json have something related to this?

[errordeveloper]

https://docs.npmjs.com/files/package.json#engines

[dlespiau]

Yes, something like this indeed :) we can't mandate the presence of a package.json file though.

[errordeveloper]

we can't mandate the presence of a package.json file though

Why? How would it be different from mandating presence of .jkcfg?

[dlespiau]

I don't know if we'll always use npm (and thus package.json) to handle our vendoring in the future. For instance deno (from the very same Ryan Dahl!) has switched away from npm to use HTTP directly:

import { serve } from "https://deno.land/std@v0.3.2/http/server.ts";

async function main() {
  const body = new TextEncoder().encode("Hello World\n");
  for await (const req of serve(":8000")) {
    req.respond({ body });
  }
}

main();

[errordeveloper]

https://whatwg.github.io/loader/#intro ...interesting.