<p dir="auto">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:</p>
<div class="highlight highlight-source-shell notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="deno new --bin project-name "><pre class="notranslate">deno new --bin project-name </pre></div>
<div class="highlight highlight-source-shell notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="deno new --lib project-name"><pre class="notranslate">deno new --lib project-name</pre></div>
<p dir="auto">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.<br>
Anyways, Thanks !</p>
<h3 dir="auto">edit: I think <a href="https://github.com/denoland/deno/issues/2584#issuecomment-506069227" data-hovercard-type="issue" data-hovercard-url="/denoland/deno/issues/2584/hovercard">my comment below</a> does a better job of explaining what I'm proposing.</h3>
<p dir="auto"><em>Bear with me on this first paragraph, I do have a point...</em></p>
<p dir="auto">While I appreciate deno eliminating <code class="notranslate">package.json</code>, there are several aspects of <code class="notranslate">package.json</code> that I find myself missing. For instance, <code class="notranslate">package.json</code> established a convention of adding / aliasing project tasks in the <code class="notranslate">"scripts"</code> section, and in general I've found a good way to learn about a new repo is to start by peaking inside <code class="notranslate">package.json</code>. It can also be helpful to know where to look to find a project's <code class="notranslate">version</code>, etc. All of this really just boils down to the fact that <code class="notranslate">package.json</code> helped push/establish a set of project conventions within the javascript / node community.</p>
<p dir="auto">I definitely don't want deno to <em>require</em> a set of project conventions, but it would be nice if deno <em>suggested</em> some project conventions / best practices.</p>
<p dir="auto">The best way that comes to mind to accomplish this would be to add a <code class="notranslate">deno new</code> (or <code class="notranslate">deno init</code>, <code class="notranslate">deno generate</code>, etc) command which scaffolds out a new project directory. This project directory could adhere to whatever the deno "best practices" are.</p>
<p dir="auto">Would you accept PRs for a feature like this? Do other people think this is a good idea?</p>
<p dir="auto">For example (obviously up for discussion):</p>
<ul dir="auto">
<li>have a top level <code class="notranslate">mod.ts</code> file
<ul dir="auto">
<li>include a comment in the file explaining it's use</li>
</ul>
</li>
<li>have a top level <code class="notranslate">deps.ts</code> file
<ul dir="auto">
<li>include a comment in the file explaining it's use</li>
</ul>
</li>
<li>have a top level <code class="notranslate">README.md</code>
<ul dir="auto">
<li>the generated readme could contain some helpful placeholder text for getting started with deno, as well as other useful "best practice" information</li>
</ul>
</li>
<li>etc</li>
</ul>
<p dir="auto">The "version 1" implementation of a <code class="notranslate">deno new</code> might just do this. But a "version 2" of a <code class="notranslate">deno new</code> 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 <code class="notranslate">deno new service my-service</code>. Etc.</p>
<p dir="auto">In this way, a <code class="notranslate">deno new</code> command could help to establish general best practices within the deno community, and it could <em>also</em> help establish project specific best practices (through user specified scaffolding templates).</p>
<p dir="auto">In some hypothetical future, I could imaging many deno "getting started" tutorials beginning with "first install deno by........Then, run <code class="notranslate">deno new hello_world</code>".</p>
<h3 dir="auto">Prior art</h3>
<ul dir="auto">
<li><a href="https://github.com/angular/angular-cli">The Angular CLI</a>
<ul dir="auto">
<li>supports custom, project specific generators (and you can install generators from npm)</li>
<li>encourages solid best practices</li>
<li>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?".</li>
<li>con of the angular-cli: it requires an <code class="notranslate">angular.json</code> file in a project's root.</li>
</ul>
</li>
</ul>
<p dir="auto"><strong>Edit</strong></p>
<p dir="auto">I suppose, for maximum flexibility, a "scaffolding template" could simply be a script. So <code class="notranslate">deno new service my_service</code> would call some script that's somehow been labeled <code class="notranslate">service</code> and pass it the <code class="notranslate">my_service</code> 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.</p>