@AndrewFinlay why don't we close this, and open an issue on nyc, we might in turn eventually open an issue on Node.js itself.

@AndrewFinlay unfortunately there are 1000s of programs in the wild that assume --help will terminate an application before the next line of code is reached.

If you structure your program appropriately .exitProcess(false), I suppose, might help make sure that the whole buffer is drained before the application exits, but I don't think this is something we can switch to being the default behavior.

I'm actually wondering out loud, is the problem that we should be calling set-blocking in nyc? This bug seems to come about when draining stderr/stdout is allowed to be non-blocking.

Adding setup and deploy functionality for firebase hosting for web, with Cloud Run for API.

I did not want to suggest that I was being dismissed

@CxRes 👍

I strongly encourage the @nodejs/tsc to consider your point of view, which you've summarized well.

What's important to me is that we take steps towards removing the --experimental flag from some form of the recursive behavior.

I agree with this (with a flag). But I want the default behavior to be tolerant on ENOENT (#35250 (comment)). I think pragmatism is mostly important in this case.

@gengjiawen I don't feel strongly about default behavior. Where I do feel strongly, is that when force=false we should throw on both ENOENT and ENODIR.

This would make it clear that force=true behaves like rm -rf, and force=false is strict behavior (similar to .NET).

The reason for my proposal was in #35171 (based on what seemed like the consensus/compromise in that thread) was to keep rmdir as truly rmdir (for deleting directories only) and then add rm to provide rimraf (rm as the universal remove function). Of course, this is breaking today but leads to more intuitive semantics.

@CxRes you've done a good job of expressing your point of view, and I haven't gotten the impression that it's being dismissed.

Node.js collaborators such as @gengjiawen are making the case that they would rather continue to see this functionality be part of rmdir -- which was the decision that the majority of Node.js collaborators made when this feature was initially added.

I am a -1 on a discussion about introducing an additional recursive method.

And I am deferring the decision about default behavior of rmdir to the TSC.

If we are changing our minds and changing rmdir itself then the flag should be called force (not strict) for the sake of consistency!!!! And to keep things backwards compatible it has to be true by default (Though I sympathize with @Trott that I do not like this default).

@ruyadorno @CxRes force works for me.

How would you (and do you plan to?) expose all the features of POSIX rm in node? My sense is that it has to be done. Do you plan to this within rmdir? or is there a plan for a rm equivalent function as well? Because it has implications here!!!

I'd like to suggest we call this out of scope for the current goal, which is getting rmdir, recursive over the finish line.

This won't prevent us from adding additional APIs in the future.

see: https://github.com/googleapis/repo-automation-bots/pull/979

Hey @taylorcode, just a gentle nudge.

We'd love to move towards the next major release of protobuf.js, and we see splitting out the CLI as its own module as one of the significant changes we'd like to make.

Any chance you could work with @gcangussu to merge his fix for tests, and then we can get this over the finish line.

This will allow api-linter to ignore our label sync logic.

CC: @lukesneeringer

@maclockard I've come to hate the default behavior of arrays, where it will consume everything following --arr a b c ..., as this creates ambiguities in the parser ... how do you use positionals in conjunctions with arrays?

I prefer to define arrays as follows my-app.js --arr 1 --arr 2 --arr 3, I like that this is more explicit. It's difficult to document this advice in a way that can be copy pasted from the help output however.

This will allow api-linter to ignore our label sync logic.

CC: @lukesneeringer

@nodejs/tsc I believe we should put this to a vote, to unblock getting rmdir/recursive out of experimental. I believe we've narrowed things down to two options (both of which involve introducing a strict flag).

1. default strict to false, which would have the behavior of rm -rf (this is the current implementation of rmdir/recursive. Setting strict to true would result in behavior that throws when given a file path, and when given a path that does not exist.
2. default strict to true, therefore changing the current behavior to throw on file paths, and on missing paths. Setting strict to false would behave like the implementation today.

CC: @Trott

As a potential date, I'd like to suggest, Friday, October 9th, 10AM - 11AM PDT.

@CxRes @Trott @gengjiawen

While it is important to find the best solution, I too wish this is not dragged out ad infinitum.

It feels like we're having trouble reaching a compromise here, I know it's not the ideal we were picturing, but I'm thinking perhaps we do go with @Trott's suggestion of a strict option, which if wet to true, has the behavior in this PR.

Then we update #35171 accordingly to reflect this.

When a command is specified through the command API or commandDir API, support a finally handler that runs at the end of the command handler both on success and failure.

Example - If there's an informational banner (new update to the tool being used) that needs to be displayed at the end of some or every command.

@nija-at there is now an onFinishCommand, which I believe should have the behavior you were looking for.

Let me know if there are any issues.

@SkeLLLa I've added the onFinishCommand to the API docs, should be working. Let us know if there are any bugs.

onFinishCommand was not documented in api docs.

Fixes #1658, #1344

Does onFinishCommand work with commandDir? And if it does, then how it should be configured?

onFinishCommand was not documented in api docs.

Fixes #1658, #1344

Exposes the hideBin helper for CJS, so that we can standardize the documentation for ESM, CJS, and Deno.

Updates documentation to suggest this approach by default.

Fixes #1648

#I'm using parse to build a CLI app using readline.

My commands execute asynchronously. Is it possible to configure the handler to take a callback (or ideally handle a returned promise)?

I think the simplest way to achieve this would be to pass any value returned by a command handler to the parse method. (So that, for example, the handler can return a promise).

My current workaround is to set a value within yars E.g.,

  let myYargs = yargs.command({
    command: 'run',
    handler: yargs => {
      yargs._result = new Promise((resolve, reject) => {
        setTimeout(() => {
          console.log('OK');
          resolve();
        }, 1000);
      });
    }
  });
  
  let rl = readline.createInterface({ ... });

  rl.prompt();
  rl.on('line', (input) => {
    myYargs.parse(['run'], (err, argv, output) => {
      Promise.resolve(argv._result).then(() => {
        rl.prompt();  // Get next line.
      });
    });
  });

Hello,

Is there a way to get an array of the non-standard options? By this I mean any parameter set the option function and similars, excluding the usual: help, version and $0.

Also I noticed that when creating an option which has a hyphen, the argv object will have it replaced by the name in camel case, e.g:

const flags = yargs
  .help('help')
  .version(() => require('../package').version)
  .showHelpOnFail(false, 'Specify --help for available options')
  .wrap(yargs.terminalWidth())
  .usage('Usage: $0 <url>')
  .command('url', 'URL to test')
  .option('output-path', {
    'describe': 'The file path to output the results',
    'type': 'string',
    'default': '',
    'group': 'Output:'
  });
console.log(flags);

output:

$ node bin/cli.js something
> { _: [ 'something' ],
   help: false,
   version: false,
   'output-path': '',
   outputPath: '',
   '$0': 'bin/cli.js' }

Is this intended, in the context of the original question how would that work?

Edit: I have found how to remove the camel cased option, only needed to add the following to my package.json:

...
"yargs": {
    "camel-case-expansion": false
  }

Thank you for all your work :)

@pedro93 there's a good chance you've moved on from this specific problem now, so I'm going to go ahead and close this.

I wanted to also point you towards parserConfiguration(), which makes it even easier to turn off settings like camel-case-expansion.

@AnthonyWC there is not an option for this. I could imagine us adding this as a configuration option to yargs-parser.

@maclockard if we were to use:

[array] [default: "default-val"] I would assume that the value is not an array, but a single string.

Curious if you had a recommendation for what might be less confusing.

@roryokane @mleguen I agree that we should push folks towards the non-singleton interface, this is the default for the new ESM support we recently added to yargs:

import yargs from 'yargs'
import { hideBin } from 'yargs/helpers'

yargs(hideBin(process.argv))
  .command('curl <url>', 'fetch the contents of the URL', () => {}, (argv) => {
    console.info(argv)
  })
  .demandCommand(1)
  .argv

I would be quite open to an update to docs that demonstrated the use of yargs() rather than yargs..

Any interested in contributing?

Look at https://docs.docker.com/compose/reference/overview/

More specifically:

Usage: docker-compose [-f <arg>...] [options] [COMMAND] [ARGS...] docker-compose -h|--help

Options: -f, --file FILE Specify an alternate compose file (default: docker-compose.yml) -p, --project-name NAME Specify an alternate project name (default: directory name) --verbose Show more output --log-level LEVEL Set log level (DEBUG, INFO, WARNING, ERROR, CRITICAL) --no-ansi Do not print ANSI control characters -v, --version Print version and exit -H, --host HOST Daemon socket to connect to

--tls Use TLS; implied by --tlsverify --tlscacert CA_PATH Trust certs signed only by this CA --tlscert CLIENT_CERT_PATH Path to TLS certificate file --tlskey TLS_KEY_PATH Path to TLS key file --tlsverify Use TLS and verify the remote --skip-hostname-check Don't check the daemon's hostname against the name specified in the client certificate --project-directory PATH Specify an alternate working directory (default: the path of the Compose file) --compatibility If set, Compose will attempt to convert deploy keys in v3 files to their non-Swarm equivalent

Commands: build Build or rebuild services bundle Generate a Docker bundle from the Compose file config Validate and view the Compose file create Create services down Stop and remove containers, networks, images, and volumes events Receive real time events from containers exec Execute a command in a running container help Get help on a command images List images kill Kill containers logs View output from containers pause Pause services port Print the public port for a port binding ps List containers pull Pull service images push Push service images restart Restart services rm Remove stopped containers run Run a one-off command scale Set number of containers for a service start Start services stop Stop services top Display the running processes unpause Unpause services up Create and start containers version Show the Docker-Compose version information

Can I immitate that form of command structure with Yargs? If not, what is the closest I can get to it?

Hey @ffMathy if you bump into any issues with the command interface, let's open some ticket for specific problems.

I'm open to specific issues/incremental work to gradually improve the output of yargs, but it's not a goal of the project to provide a level of customization for help output, that would allow you to match docker-compose exactly.

@jtbennett I tried to reproduce your issue, and I think I'm misunderstanding the problem. I ran this code:

const yargs = require('yargs')
const argv = yargs
  .version(false)
  .options({ version: { string: true, alias: "v" } }).argv
console.info(argv)

Without passing any arguments, the output is:

{ _: [], '$0': 'foo.cjs' }

Here's the output setting --version:

bencoe-macbookpro3:test-yargs bencoe$ node foo.cjs --version

{ _: [], version: '', v: '', '$0': 'foo.cjs' }

bencoe-macbookpro3:test-yargs bencoe$ node foo.cjs --version hello

{ _: [], version: 'hello', v: 'hello', '$0': 'foo.cjs' }

@vipzhicheng so, you'd prefer not to have a warning, but you want only the last command registered to show up in help, is what I'm understanding 👍

I'd prefer that we made the default behavior stricter and introduce a loose option.

I too would prefer the stricter behavior (throw on missing paths, and on attempt to remove file).

@gengjiawen what if we compromised by adding a force option. This would fit the rm -rf analogy well:

• rmdir(path): removes an empty directory, fails if it contains folders or files.
• rmdir(path, {recursive: true}: removes files and folders from folder recursively, fails if path is file, or if path does not exist.
• rmdir(path, {recursive: true, force: true}: removes files and folders, deletes file if provided as path, does not fail if path does not exist.

I would love for us to figure out a compromise that works for folks, my fear is that we'll continue keeping rmdir/recursive in an experimental state, which is ultimately worse for the user base.

@Trott to clarify, it are you advocating we'd keep the existing rm -rf behavior, and introduce a strict option. Or that we made the default behavior stricter, and introduce a loose option.

we'll also need to update this repo to stop tracking that samples/package.json in synth.metadata.

@JustinBeckwith we should make it so that when we run the linter during nightly generation, we only lint the auto generated code, so anything in the test/ or src/ folder. I was picturing perhaps we figure out a way to vary this with an environment variable that our .eslintrc.json, which we make .eslintrc.js.

This PR contains the following updates:

Release Notes

<details> <summary>prettier/prettier</summary>

v2.1.2

Compare Source

diff

Fix formatting for directives in fields (#​9116 by @​sosukesuzuki)

<!-- prettier-ignore -->

v2.1.1

Compare Source

diff

Fix format on html with frontMatter (#​9043 by @​fisker)

<!-- prettier-ignore -->

<!-- Input -->
---
layout: foo
---

Test <a
href="https://prettier.io">abc</a>.

<!-- Prettier stable -->
TypeError: Cannot read property 'end' of undefined
  ...

<!-- Prettier master -->
---
layout: foo
---

Test <a href="https://prettier.io">abc</a>.

Fix broken format for ...infer T (#​9044 by @​fisker)

<!-- prettier-ignore -->

// Input
type Tail<T extends any[]> = T extends [infer U, ...infer R] ? R : never;

// Prettier stable
type Tail<T extends any[]> = T extends [infer U, ...(infer R)] ? R : never;

// Prettier master
type Tail<T extends any[]> = T extends [infer U, ...infer R] ? R : never;

Fix format on style[lang="sass"] (#​9051 by @​fisker)

<!-- prettier-ignore -->

<!-- Input -->
<style lang="sass">
.hero
  @&#8203;include background-centered
</style>

<!-- Prettier stable -->
<style lang="sass">
.hero @&#8203;include background-centered;
</style>

<!-- Prettier master -->
<style lang="sass">
  .hero
    @&#8203;include background-centered
</style>

Fix self-closing blocks and blocks with src attribute format (#​9052, #​9055 by @​fisker)

<!-- prettier-ignore -->

<!-- Input -->
<custom lang="markdown" src="./foo.md"></custom>
<custom lang="markdown" src="./foo.md" />
<custom lang="markdown" />

<!-- Prettier stable -->
<custom lang="markdown" src="./foo.md">

</custom>
<custom lang="markdown" src="./foo.md"

/>
<custom lang="markdown"

/>

<!-- Prettier master -->
<custom lang="markdown" src="./foo.md"></custom>
<custom lang="markdown" src="./foo.md" />
<custom lang="markdown" />

v2.1.0

Compare Source

diff

🔗 Release Notes

v2.0.5

Compare Source

diff

Less: Fix formatting of :extend (#​7984 by @​fisker)

<!-- prettier-ignore -->

// Input
.class {
  &:extend(.some-class .some-other-class .some-very-loooooooooooooong-class all);
}

// Prettier 2.0.4
.class {
  &:extend(
    .some-class .some-other-class .some-very-loooooooooooooong-class all
  );
}

// Prettier 2.0.4 (Second format)
.class {
  &: extend(
    .some-class .some-other-class .some-very-loooooooooooooong-class all
  );
}

// Prettier 2.0.5
.class {
  &:extend(
    .some-class .some-other-class .some-very-loooooooooooooong-class all
  );
}

Editor integration: Use resolve if builtin require.resolve is overridden (#​8072 by @​fisker)

This fixes issues that the users of Atom and WebStorm faced with 2.0.4.

Prettier now switches to using the resolve module for resolving configuration files and plugins if it detects that require.resolve isn't Node's builtin function (doesn't support the second argument), which happens in environments like editor extensions. To force the fallback, set the PRETTIER_FALLBACK_RESOLVE environment variable to true.

v2.0.4

Compare Source

diff

Revert #​7869, "[TypeScript] format TSAsExpression with same logic as BinaryExpression" (#​7958)

v2.0.3

Compare Source

diff

JavaScript

Fix prettier-ignore inside JSX (#​7877 by @​fisker)

<!-- prettier-ignore -->

// Input
<div>
{
  /* prettier-ignore */
  x     ?   <Y/> : <Z/>
}
</div>;

// Prettier 2.0.2 (first output)
<div>
  {/* prettier-ignore */
  x     ?   <Y/> : <Z/>}
</div>;

// Prettier 2.0.2 (second output)
<div>{/* prettier-ignore */ x     ?   <Y/> : <Z/>}</div>;

// Prettier 2.0.3
<div>
  {
    /* prettier-ignore */
    x     ?   <Y/> : <Z/>
  }
</div>;

Fix regressions in styled-components template literals (#​7883 by @​thorn0)

<!-- prettier-ignore -->

// Input
const Icon = styled.div`
  background:   var(--${background});
  ${Link}:not(:first-child) {
      fill:    rebeccapurple;
  }
`;

// Prettier 2.0.2
const Icon = styled.div`
  background: var(-- ${background});
  ${Link}:not (:first-child) {
    fill: rebeccapurple;
  }
`;

// Prettier 2.0.3
const Icon = styled.div`
  background: var(--${background});
  ${Link}:not(:first-child) {
    fill: rebeccapurple;
  }
`;

Fix: line endings were not always converted properly in multiline strings and comments (#​7891 by @​sidharthv96)

<!-- prettier-ignore -->

// Input
export const IAmIncredibleLongFunctionName = IAmAnotherFunctionName(<CRLF>
  (_0: IAmIncredibleLongParameterType) => {<CRLF>
    setTimeout(() => {<CRLF>
      /*<CRLF>
        Multiline comment<CRLF>
        Multiline comment<CRLF>
        Multiline comment<CRLF>
      */<CRLF>
      console.log(<CRLF>
        "Multiline string\<CRLF>
         Multiline string\<CRLF>
         Multiline string"<CRLF>
      );<CRLF>
    });<CRLF>
  }<CRLF>
);<CRLF>

// Prettier 2.0.2
export const IAmIncredibleLongFunctionName = IAmAnotherFunctionName(<CRLF>
  (_0: IAmIncredibleLongParameterType) => {<CRLF>
    setTimeout(() => {<CRLF>
      /*<LF>
        Multiline comment<LF>
        Multiline comment<LF>
        Multiline comment<LF>
      */<CRLF>
      console.log(<CRLF>
        "Multiline string\<LF>
         Multiline string\<LF>
         Multiline string"<CRLF>
      );<CRLF>
    });<CRLF>
  }<CRLF>
);<CRLF>

// Prettier 2.0.3: same as input

Fix bug with holes in array literals (#​7911 by @​bakkot)

<!-- prettier-ignore -->

// Input
new Test()
  .test()
  .test([, 0])
  .test();

// Prettier 2.0.2
[error] in.js: TypeError: Cannot read property 'type' of null

// Prettier 2.0.3
new Test().test().test([, 0]).test();

TypeScript

Wrap TSAsExpression (#​7869 by @​sosukesuzuki)

<!-- prettier-ignore -->

// Input
const value = thisIsAnIdentifier as ThisIsAReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyLongInterface;

// Prettier 2.0.2
const value = thisIsAnIdentifier as ThisIsAReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyLongInterface;

// Prettier 2.0.3
const value =
  thisIsAnIdentifier as
  ThisIsAReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyLongInterface;

Flow

Print dangling comments for inexact object type (#​7892 by @​sosukesuzuki)

<!-- prettier-ignore -->

// Input
type Foo = {
  // comment
  ...,
};

// Prettier 2.0.2
Error: Comment "comment" was not printed. Please report this error!

// Prettier 2.0.3
type Foo = {
  // comment
  ...,
};

Do not add comma for explicit inexact object with indexer property or no properties (#​7923 by @​DmitryGonchar)

<!-- prettier-ignore -->

// Input
type T = {
  [string]: number,
  ...,
}

type T = {
  // comment
  ...,
}

// Prettier 2.0.2
type T = {
  [string]: number,
  ...,
}

type T = {
  // comment
  ...,
}

// Prettier 2.0.3
type T = {
  [string]: number,
  ...
}

type T = {
  // comment
  ...
}

HTML

Fix printing of ignored empty inline elements (#​7867 by @​fisker)

<!-- prettier-ignore -->

<!-- Input-->
<!--prettier-ignore--><span></span>
<!--prettier-ignore--><span>_</span>

<!-- Prettier 2.0.2 (first output) -->
<!--prettier-ignore--><span
></span>
<!--prettier-ignore--><span>_</span>

<!-- Prettier 2.0.2 (second output) -->
<!--prettier-ignore--><span

></span>
<!--prettier-ignore--><span>_</span>

<!-- Prettier 2.0.3 -->
<!--prettier-ignore--><span></span>
<!--prettier-ignore--><span>_</span>

Format script and style inside tags with a colon in the name (#​7916 by @​fisker)

<!-- prettier-ignore -->

<!-- Input -->
<with:colon>
<script>function foo(){      return 1}</script>
<style>a         {color:         #f00}</style>
</with:colon>

<!-- Prettier 2.0.2 -->
<with:colon>
  <script>
    function foo(){ return 1}
  </script>
  <style>
    a {color: #f00}
  </style>
</with:colon>

<!-- Prettier 2.0.3 -->
<with:colon>
  <script>
    function foo() {
      return 1;
    }
  </script>
  <style>
    a {
      color: #f00;
    }
  </style>
</with:colon>

Other changes

• Workaround for require.resolve in prettier-vscode (#​7951 by @​thorn0)
• Fix unstable Angular expression binding (#​7924 by @​fisker)
• Update isSCSS regex (#​7922 by @​fisker)
• Fix formatting of empty files (#​7921 by @​fisker)

v2.0.2

Compare Source

diff

2.0 regressions

JavaScript: Fix formatting of pseudo-elements and pseudo-classes in styled-components template literals (#​7842 by @​thorn0)

<!-- prettier-ignore -->

// Input
const Foo = styled.div`
  ${media.smallDown}::before {}
`;

// Prettier 2.0.0
const Foo = styled.div`
  ${media.smallDown}: : before{
  }
`;

// Prettier 2.0.2
const Foo = styled.div`
  ${media.smallDown}::before {
  }
`;

TypeScript: Avoid trailing commas on index signatures with only one parameter (#​7836 by @​bakkot)

TypeScript index signatures technically allow multiple parameters and trailing commas, but it's an error to have multiple parameters there, and Babel's TypeScript parser does not accept them. So Prettier now avoids putting a trailing comma there when you have only one parameter.

<!-- prettier-ignore -->

// Input
export type A = {
  a?: {
    [
      x: string
    ]: typeof SomeLongLongLongTypeName[keyof typeof SomeLongLongLongTypeName];
  } | null;
};

// Prettier 2.0.0
export type A = {
  a?: {
    [
      x: string,
    ]: typeof SomeLongLongLongTypeName[keyof typeof SomeLongLongLongTypeName];
  } | null;
};

// Prettier 2.0.2
export type A = {
  a?: {
    [
      x: string
    ]: typeof SomeLongLongLongTypeName[keyof typeof SomeLongLongLongTypeName];
  } | null;
};

Revert "markdown: fix redundant leading spaces in markdown list" (#​7847)

See #​7846

Other changes

TypeScript: Fix prettier-ignore in union types (#​7798 by @​thorn0)

<!-- prettier-ignore -->

// Input
export type a =
  // foo
  | foo1&foo2
  // prettier-ignore
  | bar1&bar2
  // baz
  | baz1&baz2;

// Prettier 2.0.0
export type a =
  // foo
  | foo1&foo2
    // prettier-ignore
  // prettier-ignore
  | (bar1 & bar2)
  // baz
  | (baz1 & baz2);

// Prettier 2.0.2
export type a =
  // foo
  | (foo1 & foo2)
  // prettier-ignore
  | bar1&bar2
  // baz
  | (baz1 & baz2);

v2.0.1

Compare Source

diff

API: Fix build script to not corrupt import-fresh module (#​7820 by @​thorn0)

v2.0.0

Compare Source

diff

🔗 Release Notes

</details>

Renovate configuration

:date: Schedule: "after 9am and before 3pm" (UTC).

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.

• [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

We had a dependency on prettier which was interfering with gts.

This PR was generated using Autosynth. :rainbow:

Synth log will be available here: https://source.cloud.google.com/results/invocations/15924f29-f418-4d50-ab06-733780204905/targets

• [ ] To automatically regenerate this PR, check this box.

@SuperITMan thanks for updating the PR 👍 will try to help merge some of these PRs soon.

Let's start putting the meeting-agenda label on issues we think we'd like to discuss on a monthly call.

I opened an issue for us to have a first meeting -- my hope is that getting a few collaborators in a room together, we can better evolve the spec.

@tmatsuo I will do an end to end test Monday 👌 (_as I don't want to release a library on Friday).

Proposal

I would like to suggest that we have our first monthly meeting in October, where:

1. start to figure out some governance for this project.
2. divide up some of the work triaging Pull Requests, and commenting on issues.

This issue will be updated with a Hangout link, agenda, and a date/time once we can agree on one.

Call to action

Join the conventional commits channel in this chat room if you're interested in joining the meeting; and we can pick a time.

@Trott are you advocating the addition of recursiveStrict, to the existing rmdir method. Which it sounds like, based on conversations so far, would have the .NET behavior:

• throw on file.
• throw on missing path.
• delete directory recursively with files.

We had a dependency on prettier which was interfering with gts.

This PR was generated using Autosynth. :rainbow:

Synth log will be available here: https://source.cloud.google.com/results/invocations/fa860a88-a304-47c4-b706-3602c4a107e7/targets

• [ ] To automatically regenerate this PR, check this box.

This PR was generated using Autosynth. :rainbow:

Synth log will be available here: https://source.cloud.google.com/results/invocations/2ae1ff2f-e35a-4922-aaf5-7f49ee08b89d/targets

• [ ] To automatically regenerate this PR, check this box.

PiperOrigin-RevId: 333132625 Source-Link: https://github.com/googleapis/googleapis/commit/470d84e263c833af5280753b8e4188432b8d5b06

:robot: I have created a release *beep* *boop*

3.0.2 (2020-09-23)

Bug Fixes

• coreos: handle coreos deprecation (#270) (38ec012)

This PR was generated with Release Please.

Thank you for providing reproduction @sramam. One thing worth trying, would be turning off source-maps.

It might be the case that TypeScript is actually adding an additional line of code in the built .js, which is legitimately not covered.

@gr2m thank you for the review.

we were bumping into an issue where probot wanted @octokit/[email protected], whereas our library release-please wanted @octokit/[email protected], I don't think we need to worry about two versions of this dependency in the tree any longer.

@gengjiawen my concern is that, I'm not convinced that our goal for a recursive method on rmdir should be to match rm -rf.

The below chart compares the directory deletion API across a variety of platforms:

• in this comparison, Node.js' rmdir recursive, was the only helper that did not throw on a missing path.
• APIs, like ruby's and python's, which have strict APIs, or lack a recursive option on rmdir, tended to offer a separate recursive method (similar to rm -rf).

My proposal is that we'd move towards either matching .NET's behavior, which matches (_@RyanZim and @CxRes's suggestions). but, consider adding a method like fs.rmdir, which throws on neither missing paths or file targets.

If we were to throw on files, but not throw on missing paths, I believe Node.js would deviate the most from other languages.

initial generation of library.

The sync pulls in latest changes in master having to do with self signed JWTs.

In addition, updates external_account clients to also handle defaultScopes.