Issue 1:
Hello. I would like to suggest/request the addition of a way to create projects using Deno CLI, like we do when using cargo for Rust. For example:

deno new --bin project-name

deno new --lib project-name

As we all know, like this, all projects will be organized with a well known structure. Perhaps we can use the config file to help us too, allowing to call external libs. And yes, I know about how deno uses url's to import stuff.

Anyways, Thanks !

Issue 2:
edit: I think my comment below does a better job of explaining what I'm proposing.

Bear with me on this first paragraph, I do have a point...

While I appreciate deno eliminating package.json, there are several aspects of package.json that I find myself missing. For instance, package.json established a convention of adding / aliasing project tasks in the "scripts" section, and in general I've found a good way to learn about a new repo is to start by peaking inside package.json. It can also be helpful to know where to look to find a project's version, etc. All of this really just boils down to the fact that package.json helped push/establish a set of project conventions within the javascript / node community.

I definitely don't want deno to require a set of project conventions, but it would be nice if deno suggested some project conventions / best practices.

The best way that comes to mind to accomplish this would be to add a deno new (or deno init, deno generate, etc) command which scaffolds out a new project directory. This project directory could adhere to whatever the deno "best practices" are.

Would you accept PRs for a feature like this? Do other people think this is a good idea?

For example (obviously up for discussion):

have a top level mod.ts file

include a comment in the file explaining it's use

have a top level deps.ts file

include a comment in the file explaining it's use

have a top level README.md

the generated readme could contain some helpful placeholder text for getting started with deno, as well as other useful "best practice" information

etc

The "version 1" implementation of a deno new might just do this. But a "version 2" of a deno new implementation could also allow scaffolding a new project from some sort of config / scaffolding template file. A "version 3" implementation might allow users to add custom named generators to a project, so someone could do deno new service my-service. Etc.

In this way, a deno new command could help to establish general best practices within the deno community, and it could also help establish project specific best practices (through user specified scaffolding templates).

In some hypothetical future, I could imaging many deno "getting started" tutorials beginning with "first install deno by........Then, run deno new hello_world".

Prior art

The Angular CLI

supports custom, project specific generators (and you can install generators from npm)

encourages solid best practices

one nice feature of the Angular CLI, is that if you invoke a command without all the required arguments, terminal prompts walk you through adding what's missing. i.e. if you try and generate a new service but forget to specify the service's name, rather than failing the cli asks "What is the name of the service?".

con of the angular-cli: it requires an angular.json file in a project's root.

Edit

I suppose, for maximum flexibility, a "scaffolding template" could simply be a script. So deno new service my_service would call some script that's somehow been labeled service and pass it the my_service argument. At that point, the feature is really just looking like a way of defining tasks for a project, which brings up new ideas. But I'll stop ideating here and see what other people are thinking.