"minify" means something else. It's more about "reducing" the size of the package.

We don't show new files to ensure package consistency. We show them to prevent publishing a broken package.

### Ignore strategy

I still don't think this text is good enough. Also, please run text through something like https://app.grammarly.com/.

The readme docs should also be in sync with the index.d.ts docs.

I meant this literally. Everything in the readme docs should be in the TS type file, including examples.

The signature does not have a name.

I still think the above text could be written more succinctly.

	type DeepKeyFilter = (objectKey: string) => boolean;

DeepKeyFilter means nothing in JS as the type is not available there.

Not sure why this is capitalized.

Recursing behavior for nested objects and objects in arrays.

Use-tab indentation.

Don't hard-wrap.

	const actualDeepFunction = mapObject(object, mapper, {deep: key => key !== 'object'});

Bump

Remove the enumerability checks.

LIVR - Is a ightweight JavaScript validator supporting Language Independent Validation Rules Specification

Thanks for the suggestion, however, the project doesn't have any changelog. You also included a lot of unrelated changes.

Maybe the naming should be more general too, in case we can to include other things in the preload script in the future.

Actually, I think it would be better to do it the other way around and expose our preload thing, so the user could include it if they call setPreloads themselves.

This needs to explain why the option exists and why the user should not call setPreloads themselves.

Yes, I can do a major release.

@Idered Still interested in finishing this?

https://github.com/rocketlaunchr/electron-alert

Thanks for the suggestion. I'm going to pass on this. I think it's better to just use SweetAlert2 directly in the browser process and use the native dialog for stuff in the main process.

I don't think this is clear enough as being as fish when animated. To me, it just looks like noise. I would drop this one.

I think it would be better to use a descriptive name.

	"futurebar": {

This is missing a square.

@Richienb Are you interested in finishing this or should I close?

I do not see a reason why it will not pass. What issues do you anticipate will happen when merged? As far as I know, actions/checkout@v2 had a breaking change, but that was taken care by setting the fetch-depth to 0.

I think I explained it pretty clearly in the linked comment. The readme here does not pass all the awesome-lint rules.

This's #1703 closed pull request.

<!-- Congrats on creating an Awesome list! 🎉 -->

<!-- Please fill in the below placeholders -->

topological data analysis (TDA) is an approach to the analysis of datasets using techniques from topology. This list is handy for those who want to know more about TDA's theory and Tools in both mathematics and computer science.

PRs Reviewed: #1701 #1684 #1792

By submitting this pull request I confirm I've read and complied with the below requirements 🖖

Please read it multiple times. I spent a lot of time on these guidelines and most people miss a lot.

Requirements for your pull request

• Don't waste my time. Do a good job, adhere to all the guidelines, and be responsive.
• You have to review at least 2 other open pull requests. Try to prioritize unreviewed PRs, but you can also add more comments to reviewed PRs. Go through the below list when reviewing. This requirement is meant to help make the Awesome project self-sustaining. Comment here which PRs you reviewed. You're expected to put a good effort into this and to be thorough. Look at previous PR reviews for inspiration.
• You have read and understood the instructions for creating a list.
• This pull request has a title in the format Add Name of List.
  • ✅ Add Swift
  • ✅ Add Software Architecture
  • ❌ Update readme.md
  • ❌ Add Awesome Swift
  • ❌ Add swift
  • ❌ Adding Swift
  • ❌ Added Swift
• Your entry here should include a short description about the project/theme of the list. It should not describe the list itself. The first character should be uppercase and the description should end in a dot. It should be an objective description and not a tagline or marketing blurb.
  • ✅ - [iOS](…) - Mobile operating system for Apple phones and tablets.
  • ✅ - [Framer](…) - Prototyping interactive UI designs.
  • ❌ - [iOS](…) - Resources and tools for iOS development.
  • ❌ - [Framer](…)
  • ❌ - [Framer](…) - prototyping interactive UI designs
• Your entry should be added at the bottom of the appropriate category.
• The suggested Awesome list complies with the below requirements.

Requirements for your Awesome list

• Has been around for at least 30 days.<br>That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent.
• Don't open a Draft / WIP pull request while you work on the guidelines. A pull request should be 100% ready and should adhere to all the guidelines when you open it.
• Run awesome-lint on your list and fix the reported issues. If there are false-positives or things that cannot/shouldn't be fixed, please report it.
• The default branch should be named main, not master.
• Includes a succinct description of the project/theme at the top of the readme. (Example)
  • ✅ Mobile operating system for Apple phones and tablets.
  • ✅ Prototyping interactive UI designs.
  • ❌ Resources and tools for iOS development.
  • ❌ Awesome Framer packages and tools.
• It's the result of hard work and the best I could possibly produce. If you have not put in considerable effort into your list, your pull request will be immediately closed.
• The repo name of your list should be in lowercase slug format: awesome-name-of-list.
  • ✅ awesome-swift
  • ✅ awesome-web-typography
  • ❌ awesome-Swift
  • ❌ AwesomeWebTypography
• The heading title of your list should be in title case format: # Awesome Name of List.
  • ✅ # Awesome Swift
  • ✅ # Awesome Web Typography
  • ❌ # awesome-swift
  • ❌ # AwesomeSwift
• Non-generated Markdown file in a GitHub repo.
• The repo should have awesome-list & awesome as GitHub topics. I encourage you to add more relevant topics.
• Not a duplicate. Please search for existing submissions.
• Only has awesome items. Awesome lists are curations of the best, not everything.
• Does not contain items that are unmaintained, has archived repo, deprecated, or missing docs. If you really need to include such items, they should be in a separate Markdown file.
• Includes a project logo/illustration whenever possible.
  • Either centered, fullwidth, or placed at the top-right of the readme. (Example)
  • The image should link to the project website or any relevant website.
  • The image should be high-DPI. Set it to maximum half the width of the original image.
• Entries have a description, unless the title is descriptive enough by itself. It rarely is though.
• Includes the Awesome badge.
  • Should be placed on the right side of the readme heading.
    • Can be placed centered if the list has a centered graphics header.
  • Should link back to this list.
• Has a Table of Contents section.
  • Should be named Contents, not Table of Contents.
  • Should be the first section in the list.
  • Should only have one level of nested lists, preferably none.
• Has an appropriate license.
  • We strongly recommend the CC0 license, but any Creative Commons license will work.
    • Tip: You can quickly add it to your repo by going to this URL: https://github.com/<user>/<repo>/community/license/new?branch=master&template=cc0-1.0 (replace <user> and <repo> accordingly).
  • A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. Neither are WTFPL and Unlicense.
  • Place a file named license or LICENSE in the repo root with the license text.
  • Do not add the license name or text to the readme. GitHub already shows the license name at the top of the repo.
  • To verify that you've read all the guidelines, please comment on your pull request with just the word unicorn.
• Has contribution guidelines.
  • The file should be named contributing.md. Casing is up to you.
• Has consistent formatting and proper spelling/grammar.
  • The link and description are separated by a dash. <br>Example: - [AVA](…) - JavaScript test runner.
  • The description starts with an uppercase character and ends with a period.
  • Consistent and correct naming. For example, Node.js, not NodeJS or node.js.
• Doesn't include a Travis badge.<br>You can still use Travis for list linting, but the badge has no value in the readme.
• Doesn't include an Inspired by awesome-foo or Inspired by the Awesome project kinda link at the top of the readme. The Awesome badge is enough.

Go to the top and read it again.

I'm going to close this for now as the list is not close to being added and there's no progress. I would recommend reading through the guidelines more closely, work more on the list, and try submitting again sometime in the future (after at least 3 months).

There are still many things that are not followed:

Includes a succinct description of the project/theme at the top of the readme. (Example)

Entries have a description, unless the title is descriptive enough by itself. It rarely is though.

And more.

https://github.com/sindresorhus/awesome/pull/1802#issuecomment-654365940 is still not done. Please do a good effort on that before commenting back here. Look at other awesome lists for inspiration.

Looks weird when you repeat "astronomy" in the description.

Ansible is an open source toolkit, written in Python, it is used for Configuration Management, Application Deployment, Continuous Delivery, IT infrastructure automation and automation in general.

This should not be titled-cased.

Entry descriptions should not be in title-case. Same with the section descriptions.

The image should link to the project website or any relevant website.

Linkify Ansible in Ansible is an open source toolkit, written in Python to its website.

The PR title is incorrect.

❯ awesome-lint https://github.com/keller-mark/awesome-biological-visualizations
✖ Linting

  README.md:91:3
  ✖  91:3  Invalid list item link URL  remark-lint:awesome-list-item

  1 error

https://github.com/sindresorhus/awesome-lint

I think it would be useful if your list had a more verbose description of its purpose below the current tagline. Something like:

Web-based biology-related visualization tools are often scattered across the internet and difficult to discover. They may be found on GitHub, Twitter, or linked from scientific papers. These tools can be very useful to scientists looking to visualize biological data in the context of diseased or healthy humans or model organisms.

How is this different/better than all the other validation packages already in the list?

Please follow the contribution guidelines: https://github.com/sindresorhus/awesome-nodejs/blob/master/contributing.md

Hey, I recently built a stats tool for NPM that shows the weekly downloads as of npmjs.org and also the number of dependents (which is an indicator for the popularity of the package). So it might fit in the list of already-existing npm stat tools.

https://my-npm-stats.org/

Also, it's npm, not NPM.

I think you should find some users, get some feedback, iterate, and then submit again at a later point when the site is more mature and you've figured it more out.

You're asking the wrong person as I'm not your target audience.

@sindresorhus Please consider adding handpick as it become more stable and feature-rich. People at mozilla-it start using it and I had lot of success with clients to speed-up their pipelines. Check out the examples to get an idea how it works.

There's also a new guideline that requires 40 stars (to make sure submitted entries are things that are actually used by users): https://github.com/sindresorhus/awesome-npm/blob/master/contributing.md

The project readme should clearly describe what it is and what problems it solves.

It was inspired by tools like django admin, railsadmin and active admin. It reached 2k stars this weekend so I decided that this is the right moment to post it here.

By submitting this pull request, I promise I have read the contribution guidelines twice and ensured my submission follows it. I realize not doing so wastes the maintainers' time that they could have spent making the world better. 🖖

⬆⬆⬆⬆⬆⬆⬆⬆⬆⬆

The description starts with an uppercase character and ends with a period.

Bump

Add Awesome Illustrations: A curated list of awesome illustrations & tools ✨ https://github.com/MrPeker/awesome-illustrations#readme

It's a list of design resources specifically for illustrations. I think it's a great collection of illustrations.

By submitting this pull request I confirm I've read and complied with the below requirements 🖖

Reviewed PRs:

• #1803
• #1802

**Please read it multiple times. I spent a lot of time on these guidelines and most people miss a lot.**
## Requirements for your pull request

- **Don't waste my time.** Do a good job, adhere to all the guidelines, and be responsive.
- **You have to review at least 2 other [open pull requests](https://github.com/sindresorhus/awesome/pulls?q=is%3Apr+is%3Aopen).**
	Try to prioritize unreviewed PRs, but you can also add more comments to reviewed PRs. Go through the below list when reviewing. This requirement is meant to help make the Awesome project self-sustaining. Comment here which PRs you reviewed. You're expected to put a good effort into this and to be thorough. Look at previous PR reviews for inspiration.
- You have read and understood the [instructions for creating a list](create-list.md).
- This pull request has a title in the format `Add Name of List`.
	- ✅ `Add Swift`
	- ✅ `Add Software Architecture`
	- ❌ `Update readme.md`
	- ❌ `Add Awesome Swift`
	- ❌ `Add swift`
	- ❌ `Adding Swift`
	- ❌ `Added Swift`
- Your entry here should include a short description about the project/theme of the list. **It should not describe the list itself.** The first character should be uppercase and the description should end in a dot. It should be an objective description and not a tagline or marketing blurb.
	- ✅ `- [iOS](…) - Mobile operating system for Apple phones and tablets.`
	- ✅ `- [Framer](…) - Prototyping interactive UI designs.`
	- ❌ `- [iOS](…) - Resources and tools for iOS development.`
	- ❌ `- [Framer](…)`
	- ❌ `- [Framer](…) - prototyping interactive UI designs`
- Your entry should be added at the bottom of the appropriate category.
- The suggested Awesome list complies with the below requirements.

## Requirements for your Awesome list

- **Has been around for at least 30 days.**<br>That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent.
- Don't open a Draft / WIP pull request while you work on the guidelines. A pull request should be 100% ready and should adhere to all the guidelines when you open it.
- Run [`awesome-lint`](https://github.com/sindresorhus/awesome-lint) on your list and fix the reported issues. If there are false-positives or things that cannot/shouldn't be fixed, please [report it](https://github.com/sindresorhus/awesome-lint/issues/new).
- The default branch should be named [`main`, not `master`](https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/).
- **Includes a succinct description of the project/theme at the top of the readme.** [(Example)](https://github.com/willempienaar/awesome-quantified-self)
	- ✅ `Mobile operating system for Apple phones and tablets.`
	- ✅ `Prototyping interactive UI designs.`
	- ❌ `Resources and tools for iOS development.`
	- ❌ `Awesome Framer packages and tools.`
- It's the result of hard work and the best I could possibly produce.
	**If you have not put in considerable effort into your list, your pull request will be immediately closed.**
- The repo name of your list should be in lowercase slug format: `awesome-name-of-list`.
	- ✅ `awesome-swift`
	- ✅ `awesome-web-typography`
	- ❌ `awesome-Swift`
	- ❌ `AwesomeWebTypography`
- The heading title of your list should be in [title case](https://capitalizemytitle.com/) format: `# Awesome Name of List`.
	- ✅ `# Awesome Swift`
	- ✅ `# Awesome Web Typography`
	- ❌ `# awesome-swift`
	- ❌ `# AwesomeSwift`
- Non-generated Markdown file in a GitHub repo.
- The repo should have `awesome-list` & `awesome` as [GitHub topics](https://help.github.com/articles/about-topics). I encourage you to add more relevant topics.
- Not a duplicate. Please search for existing submissions.
- Only has awesome items. Awesome lists are curations of the best, not everything.
- Does not contain items that are unmaintained, has archived repo, deprecated, or missing docs. If you really need to include such items, they should be in a separate Markdown file.
- Includes a project logo/illustration whenever possible.
	- Either centered, fullwidth, or placed at the top-right of the readme. [(Example)](https://github.com/sindresorhus/awesome-electron)
	- The image should link to the project website or any relevant website.
	- **The image should be high-DPI.** Set it to maximum half the width of the original image.
- Entries have a description, unless the title is descriptive enough by itself. It rarely is though.
- Includes the [Awesome badge](awesome.md#awesome-badge).
	- Should be placed on the right side of the readme heading.
		- Can be placed centered if the list has a centered graphics header.
	- Should link back to this list.
- Has a Table of Contents section.
	- Should be named `Contents`, not `Table of Contents`.
	- Should be the first section in the list.
	- Should only have one level of [nested lists](https://commonmark.org/help/tutorial/10-nestedLists.html), preferably none.
- Has an appropriate license.
	- **We strongly recommend the [CC0 license](https://creativecommons.org/publicdomain/zero/1.0/), but any [Creative Commons license](https://creativecommons.org/choose/) will work.**
		- Tip: You can quickly add it to your repo by going to this URL: `https://github.com/<user>/<repo>/community/license/new?branch=master&template=cc0-1.0` (replace `<user>` and `<repo>` accordingly).
	- A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. Neither are WTFPL and [Unlicense](https://unlicense.org).
	- Place a file named `license` or `LICENSE` in the repo root with the license text.
	- **Do not** add the license name or text to the readme. GitHub already shows the license name at the top of the repo.
	- To verify that you've read all the guidelines, please comment on your pull request with just the word `unicorn`.
- Has [contribution guidelines](awesome.md#include-contribution-guidelines).
	- The file should be named `contributing.md`. Casing is up to you.
- Has consistent formatting and proper spelling/grammar.
	- The link and description are separated by a dash. <br>Example: `- [AVA](…) - JavaScript test runner.`
	- The description starts with an uppercase character and ends with a period.
	- Consistent and correct naming. For example, `Node.js`, not `NodeJS` or `node.js`.
- Doesn't include a Travis badge.<br>You can still use Travis for list linting, but the badge has no value in the readme.
- Doesn't include an `Inspired by awesome-foo` or `Inspired by the Awesome project` kinda link at the top of the readme. The Awesome badge is enough.

**Go to the top and read it again.**

Closing for lack of response.

The description is too verbose. Try to focus on what matters.

Bump

Bump

Turns out the recording actually starts right when we call recorder.start(). The .onStart event is emitted 2-3 seconds later. So the fix is to simply not wait for that event. I'm suspecting that even is when the recording starts writing to the file on disk, not when the actual recording starts.

Fixes #1 Related https://github.com/wulkano/Kap/issues/850#issuecomment-642127662

I'm recording the screen because I need to show some visualizations over a video I'm reproducing. I need to know when the recording starts so I can then play the video at the same time. Now the video it's playing almost a second after it has started recording. I'm still trying to figure out if there's a problem on my code causing this but I see one of the comments on the code says // R is printed by Swift when the recording **actually** starts like if the "actually" has air quotes or something.

So, is there a know lapse of time that passes from when the recording starts until the promise resolves? Can I do something about this?

Thanks!

Closing in favor of https://github.com/sindresorhus/modern-normalize/issues/44.

See https://github.com/sindresorhus/modern-normalize/pull/31#issuecomment-502339135

If the proposal here is just to provide the template string, then it doesn't need to have any mention of styled-components, could use a more generic name as other CSS-in-JS packages like Linaria could use it too afaik.

Correct

Trivial declaration file for typescript so VS Code won't yell while editing webpack config file...

https://github.com/sindresorhus/eslint-formatter-pretty/issues/52

If anyone wants to work on this, see the initial attempt and feedback in https://github.com/sindresorhus/eslint-formatter-pretty/pull/50.

Bump

Closing for lack of response.

Bump

You're writing "return" twice.

Bump

Can you add a type test to index.test-d.ts?