Modelling devDependencies and scripts

[nayeemrmn]

There will never be a need for a project to explicitly tell Deno about its dev dependencies. There is no package manager and this is all handled naturally by imports. However, we should have a convention that documents all of a project's dev dependencies in one place. A dev_deps.ts mirroring the deps.ts.

There was also discussion about how to model the "scripts" field in package.json. We should try to solve this in a way that naturally introduces the above. i.e. combine the "scripts" and "devDependencies" fields into one convention.

The closest suggestion that exists for this, from #2584 (comment), is to have a top-level tools.ts which looks like

import { register } from "https://deno.land/std/tools/mod.ts";
register({
  start: "deno run -A server.ts",
  lint: "eslint src/**/*.ts",
  build: "deno run -A https://deno.land/x/webpack@v0.1.0/mod.ts ..."
});

The webpack dev dependency is "documented" in that string.

One suggestion is to rethink this so that https://deno.land/x/webpack/mod.ts is a static import of tools.ts. We could tell authors of tools to export something like a main(args: String[]). This function could be accepted as a value in the object given to register() instead of just accepting strings. Also, maybe it shouldn't depend on something from std?

import * as eslint from "https://deno.land/x/eslint@v0.1.0/mod.ts";
import * as webpack from "https://deno.land/x/webpack@v0.1.0/mod.ts";

Deno.tools({
  start: "deno run -A server.ts",
  lint: eslint.main,
  build: webpack.main
});

[David-Else]

Also, maybe it shouldn't depend on something from std?

import * as eslint from "https://deno.land/x/eslint@v0.1.0/mod.ts";
import * as webpack from "https://deno.land/x/webpack@v0.1.0/mod.ts";

Deno.tools({
start: "deno run -A server.ts",
lint: eslint.run,
build: webpack.run
});

This looks great, having to import anything considered a 'built in' feature seems wrong, importing all the dev dependencies in one file up at the top looks good to me. Easy to read and reason about.

I use the VS Code NPM Scripts explorer to run everything. I can see an awesome future where it works with Deno too.

[iAmNathanJ]

FWIW I have a (rough) task runner I've been working on that somewhat resembles the patterns being suggested here. Might be of interest. https://github.com/iAmNathanJ/devo

[ry]

I think this is something that is better developed outside of std for now (like @iAmNathanJ has done) - since it's experimenting with new patterns. I can imagine this developing into a pattern that many people use and it then making sense to merge into std, but we have finite bandwidth to maintain std and I'd rather focus that on stuff we know we need.

So maybe a good idea - but not something I want to take on right now :)