Enable deno in vscode

[zifeo]

If ghjk.ts is localed at the same directory than a .vscode/settings.json file, inject the following idempotently:

  "deno.enablePaths": [
    "./ghjk.ts"
  ]

[destifo]

@zifeo So that's why I was having "Cannot find type Deno" error, I was thinking of working on this issue. Should I add the code to add the config to settings.json when the command ghjk ports sync or when do you think the config should be added?

[zifeo]

@destifo we have a concept of modules, and for that features I would push to have a dedicated one that can ensure this kind of the structures on all the situations (e.g. the changes should be enforced again if erased in a merge). You can then "hook" the module at the correct location in the call stack, @Yohe-Am may be able to advise for that or have another opinion?

[Yohe-Am]

Hey, yeah. I've been thinking about this a bit and I think this implementation can be split between the tasks and the TBD environments module #24 which is responsible for managing the env vars and running custom hooks when we cd into a ghjk active dir. To elaborate:

We have the tasks module currently, a generic task runner which only has a beta implementation. Right now, you can define tasks in the ghjkfile (i.e. the ghjk.ts) but you can also easily import them from other scripts possibly even from a remote hosted module.

This looks something like...

//remote.ts

export const helpers = () => ({
    helper: task("helper", () => { /* do stuff */ }),
    helper2: task("helper2", () => { /* do stuff 2 */ })
});

// ghjk.ts

import { helpers } from "https://remote.ts";

const { helper } = helpers();

task("myTask", {
  dependsOn: [helper],
  async fn() { /* do stuff */ }
})

This works well enough today though we might want to add a config on tasks that allows us to hide them in the CLI. ghjk x helper clutters the CLI here for e.g. even though we only mean to depend on it.

What I'm getting at is that we can have a such a "library" of helper tasks exposed by default on the ghjk CLI. The functionality in this ticket could then be part of a generic init task. Once the environments module #24 lands, we can run hooks from this "library" whenever we cd into the ctx directory. (Ofcourse, enabling these default helpers can be opt-out-able)

To aid this, we might want to introduce a "task group" functionality of sorts to group certain tasks together like so...

$ ghjk x build front
$ ghjk x build back

...the most straightfwd implementation of which I can think of which is using the whitespace in the task names to figure it out.

task("build front", async () => { /* build frontend */ } )
task("build back", async () => { /* build backend */ })

This is relevant because we'd want the default helpers to be grouped together.

$ ghjk x helpers init # I imagine a general purpose, prompt-driven init helper here
$ ghjk x helpers init vscode # handles this ticket
$ ghjk x helpers init tsconfig # handles #19
$ ghjk x helpers lint # handles #33

I think explicit init commands is a better fit to avoid surprise but like I mentioned, this can be integrated with #24 to make it automatic. Wdyt?