feat: Add init command #1358

joshcanhelp · 2024-04-06T03:40:03Z

This adds a new command, init, that adds the necessary files and configuration to an existing npm project. It attempts to auto-detect the module type and package manager being used, falling back to a prompt if necessary. Usage is covered in the examples.

Addresses #999

src/commands/init.ts

joshcanhelp · 2024-04-06T16:45:12Z

src/commands/init.ts

+        bin,
+        commands: './dist/commands',
+        dirname: bin,
+        ...packageJSON.oclif,


I have this at the bottom to override anything that the init command is doing. This seems like the right thing to do in an existing project.

joshcanhelp · 2024-04-06T17:02:41Z

src/commands/init.ts

+  static summary = 'Initialize a new oclif CLI'
+
+  async run(): Promise<void> {
+    const outputDir = await this.getFlagOrPrompt({defaultValue: './', name: 'output-dir', type: 'input'})


I went back and forth on whether this should be a flag or an arg. I landed on flag to better match how generate works but I don't feel strongly either way.

Do you think an output-dir flag or arg is really helpful in this scenario? Wondering if you should just drop it altogether

If you keep it, I like it as a flag

I think it's good to allow tools like this to operate in other directories, like npm --prefix /path/to/project or git -C /path/to/project

src/commands/init.ts

joshcanhelp · 2024-04-06T17:06:35Z

src/commands/init.ts

+
+    let moduleType = this.flags['module-type']
+    if (!moduleType || !validModuleTypes.includes(moduleType)) {
+      if (packageJSON.type === 'module') {


I think this is about as good as we can do with module auto-detection here. We could parse tsconfig.json (module seemed to be the strongest signal) but I 'm not sure we want to go that far with something that doesn't require TS.

I think checking type in package.json is good enough. You could also use get-package-type which we use in @oclif/core. The only benefit to that package is that it caches the result. But probably not worth in this scenario since we're only ever going to check once

mdonnalley

Looking good! Just a few questions/changes

I'll checkout this out later today to test it out

mdonnalley · 2024-04-08T16:23:25Z

src/commands/init.ts

+
+    let moduleType = this.flags['module-type']
+    if (!moduleType || !validModuleTypes.includes(moduleType)) {
+      if (packageJSON.type === 'module') {


I think checking type in package.json is good enough. You could also use get-package-type which we use in @oclif/core. The only benefit to that package is that it caches the result. But probably not worth in this scenario since we're only ever going to check once

mdonnalley · 2024-04-08T16:25:53Z

src/commands/init.ts

+
+    const template = moduleType === 'ESM' ? 'hello-world-esm' : 'hello-world'
+    const repoPath = join(location, '_tmp-template')
+    await clone(template, repoPath)


What are your thoughts on adding bin/run.js and bin/dev.js templates to the /templates directory and using those instead?

I think that would be much better than cloning a repo and hoping the permissions and everything works.

Would that make maintenance on your template repos more arduous?

Yeah that would be the downside but we already have to maintain the other templates to keep up with the hello-world templates so it's not a new problem.

I think I'd prefer templates for now. We can always solve that problem later

@mdonnalley - Just to be clear ... are you saying you want me to use templates added to this repo for this PR?

Yes, I would prefer for you to add templates for all the bin scripts to the templates/ directory.

You'll just need to insert __dirname or import.meta.url based on the module type

mdonnalley · 2024-04-08T16:27:39Z

src/commands/init.ts

+        }
+      }
+
+      await exec(`${packageManager} install @oclif/core`, {cwd: location, silent: false})


yarn install @oclif/core needs to be yarn add @oclif/core

Good catch, I haven't used yarn in a while ... looks like that's the same in pnpm

mdonnalley · 2024-04-08T16:28:30Z

src/commands/init.ts

+  static summary = 'Initialize a new oclif CLI'
+
+  async run(): Promise<void> {
+    const outputDir = await this.getFlagOrPrompt({defaultValue: './', name: 'output-dir', type: 'input'})


Do you think an output-dir flag or arg is really helpful in this scenario? Wondering if you should just drop it altogether

If you keep it, I like it as a flag

joshcanhelp · 2024-04-09T16:01:31Z

@mdonnalley - Alright, we should be good here 👍

mdonnalley

This looks good to me - thanks again for the contribution!

I'm going to merge this into a separate branch before merging to main so I can add some integration tests before it's released.

Depending on what the tests reveal, I might make some modifications but your initial commit will still be in the history so you'll get attributed with the bulk of the work. Hopefully that works for you

* feat: add init command (#1358) * feat: add init command * refactor: validation for module types and package managers * feat: add default comman discovery * feat: allow existing oclif config to override new * feat: keep existing bin entries * feat: command description and examples * fix: remove colons from prompts * fix: default bin value to empty string if dir not found * fix: path permissions to clone repo and ensure bin dir exists * fix: mkdir recursive to ensure bin directory exists * fix: update package command in init * feat: switch repo cloning to ejs template * feat: tests and ux improvements * fix: more ux improvements * fix: return type on getFlagOrPrompt * chore: apply suggestions from code review Co-authored-by: Josh Cunningham <josh@joshcanhelp.com> * feat: add back module-type flag --------- Co-authored-by: Josh Cunningham <josh@joshcanhelp.com>

feat: add init command

d1f6cc3

salesforce-cla bot added the cla:signed label Apr 6, 2024