Given the immense popularity of Docker and the need to harden it different per platform (see ideas below) - we'd like to start writing a Docker best practices section.

You're welcome to contribute ideas and write best practices - writing and brainstorming will people is an amazing way to deepen your Docker understanding.

At first, we want to collect ideas for best practices, solidify a list

I'm getting bit with failing documentation builds because I'm writing docstrings that JSDoc doesn't like (specifically, TS-style). But there's no linting happening before getting to Netlify.

We may be able to make JSDoc just check the syntax and exit (and make it part of the lint scripts).

This is moot if we want to move forward with maintaining our own TS types (for which there is an op

Current behavior

Hello, I would simply like to request that the documentation for find() (https://enzymejs.github.io/enzyme/docs/api/ShallowWrapper/find.html) be updated to reflect its snapshot-nature. For example, in a situation where clicking a button updates state under the hood...

   // some set up code goes here. 

    const deleteButton = wrapper.find('[data-enzyme-id

Is there any guide on writing a launcher? Looking over the current implementations there didn't seem to be much consistency. Looking for best practices.

The second example in section 1.1 says:

expect(result.approved).to.be.false;

It should be:

expect(result.approved).to.be.true;

(I'm guessing you made it false so you could simulate the error output in the next picture.)

Pre-check

• [x ] I'm aware that I can edit the docs and submit a pull request

Describe the improvement

I'd like to report

• Unclear documentation
• A typo
• Missing documentation
• Other

Description of the improvement / report
Auto Completion page suggests ho

The features section in the docs states that nodemon is available in the project, when it's clearly not. It's not added as a dependency or as a command in the project. Maybe remove this from the docs or actually add nodemon?

Hi, I've been using this library for sending a coverage report from a dockerized build hosted in Travis-CI.

At first I was unable to understand why coveralls.io builds had a coverage report but not a branch name nor a commit msg. At the end I had to read the library's code and this article to unders

In dareid/chakram#6 (comment) I note the inclusion of the extra word 'comprise' for request assertion chains.

I can't find documentation for this keyword through an API search or elsewhere on the web.

It may be because one of the unfortunate costs of building sentence-like build chains - is that each function is a dictionary word not a distinctive comp

Is your feature request related to a problem? Please describe.
Need to turn on the following features: Allow selection, copying of titles or descriptions.

It's easy to copy the title and then find the matching location in the code.

Describe the solution you'd like
Add new options or use a similar scheme:

#report {
 user-select: text;
}

Builds that change an interface or have backwards-incompatible changes in them will fail an Appveyor build because they pull in pact from NPM rather than the in-build changes.

See https://ci.appveyor.com/project/pact-foundation/pact-js/builds/32277939 for an example.

We should npm link @pact-foundation/pact as we do in build.sh on Linux, so that the examples are always tested against the

These work, for Vue + Typescript + Webpack:

1. ./.storybook/config.js:

import { configure } from '@storybook/vue'

// automatically import all files ending in *.stories.js
const req = require.context('../src/stories', true, /.stories.ts$/);
function loadStories() {
  req.keys().forEach((filename) => req(filename));
}

configure(loadStories, module)

2. ./.storybook/webpac

Currently if I run this migrating from mocha, in addition to the modifications I'd expect to see surrounding assertions etc, it is being converted to test. Since it is an alias of test, I'm wondering why there's a preference over test? Also if this is the case, is there a way of avoiding this replacement in the jest-codemods utility currently? This creates a lot of noise in spec convers

Issue description or question

The coverage markers usually remain green for the lines that contain the test declaration in Jest. This is usually not a problem until those tests are collapsed (folded). When the tests are folded, then it becomes more difficult to tell that the tests did not run just by scanning the coverage markers.

For example:

![image](https://user-images.githubuserc

The README for nyc states:

Please start with the pre-configured @istanbuljs/nyc-config-babel preset [...]

The README for nyc-config-babel states:

Handy default configuration for instrumenting your babel-backed project [...]

When I configure my babel project without this package, everything seems to work correctly. None of the documentation I've found explains why I should pull in t

First of all, thanks for the interesting and useful solution, which jsdom-global definitely is.
Though let me notice there is still a difference between the real browsers behavior and the environment emulated on the node using jsdom-global. In the real browser:

window.foo=1;
typeof foo; // => 'number'

Unfortunately in the emulated environment on node -r jsdom-global/register:

Hey,

Im going through examples in readme and in https://volument.com/baretest but as far as i can tell, just copy pasting them throws errors.

It would be nice to have a repo to clone to:

1. see how to set it up. currently i dont understand what this supposed to be const test = require('.')('sum'), in docs. And its not lack of my js knowledge that bothers me.
2. verify the performance cl