chore(ts): init typescript conf + tsify tokenize-arg-string

[QmarkC]

First step of #265, "Switch to typescript".

• Add initial TypeScript configuration
  Modeled after TypeScript configuration used in yargs/yargs.

  Matched semantic versions used in yargs package.json for added devDependencies.

  • Add/Update configs related to build output folder.
  • Move coverage thresholds from npm script to .nycrc config

• Add lint configuration for .ts files.
  Modeled after yargs setup.

  • Switch from standard to standardx
  • Add .editorconfig
  • Add ESLint config

• Convert lib/tokenize-arg-string.js and test/tokenize-arg-string.js to TypeScript

• Update index.js to use tokenizeArgString from build

[bcoe]

Left a few comments, but this is looking solid.

[bcoe]

@QmarkC this is looking pretty solid to me, happy to take the PR whenever you're ready.

[QmarkC]

@QmarkC this is looking pretty solid to me, happy to take the PR whenever you're ready.

I've updated the PR based on the current feedback.
There is still an open question regarding the type to use the argString argument. I would like to get confirmation on using string | any[] or if this should be more strict such as string | (string | number)[]. The same type will need to be used for Parser, Parser.detailed, and parse.

Also should I rebase to merge all the commits for cleaner history? That's what I typically do after getting feedback on a PR.

[bcoe]

@QmarkC I would like to stick with the string | any[], as other changes would be breaking (the "" + arg is coercing any types into a string any ways). The current approach looks good to me.

Looks like your rebased already, in general this is optional, as I squash and merge when I land 👍 I sometimes do so any ways on a large feature.

[bcoe]

we can land this as soon as @mleguen approves. Thanks for getting this work started @QmarkC.

[bcoe]

@QmarkC I've been talking with @mleguen, I think we'll make the final TypeScript release of yargs a major release any ways... so, let's plan that this work on yargs-parser will be a major, at which point let's make a PR to drop Node 8, move to Node 10, and move to the latest version of decamelize.

The problem with decamelize@3.x is the xregexp dep, which is 700kb.

[mleguen]

Thanks a lot! Ready to merge once engines requirements in package.json is in line with tsc output.

[mleguen]

If we do want to continue supporting node 6 in yargs-parser, then the target needs to be changed in tsconfig.json (and in .eslintrc too, I think), as node 6 supports only 17% of es2017 (see https://node.green/#ES2017).

[mleguen]

But as I see we no longer do tests on node 6, I suggest upgrading the engines requirements to "node": ">=8" here

[bcoe]

@mleguen @QmarkC since we're going to need to take on a breaking change any ways, let's just make it >=10, but I'll do this in a separate PR.

[QmarkC]

#278

[mleguen]

OK, but opening #278 does not change the issue here: tsconfig.json and .eslintc are still incoherent with package.json?

[QmarkC]

@mleguen engines.node in package.json has been updated to >=10, ESLint parserOptions.ecmaVersion updated to 2018, and updated tsconfig.json to remove es2017 so it will use es2018 from gts/tsconfig-google.json.

[bcoe]

@QmarkC master has the latest decamelize and camelcase now 👍

Resolve conflicts, make sure you've addressed @mleguen's feedback, and we'll merge this?

[QmarkC]

Thanks a lot! Ready to merge once engines requirements in package.json is in line with tsc output.

@bcoe @mleguen this should be resolved now with the update to node >=10, and es2018 for ESLint and tsconfig.json.

I also created another branch, 265-tsify-yargs-parser, that has this first step, second step to tsify yargs-parser, and cleans up the commits. Let me know if you want to close this PR in favor of that branch.