profile
viewpoint
Jamie Kyle jamiebuilds Discord Oakland, CA https://jamie.build/ Code Ruins Everything Around Me

gaearon/react-transform-boilerplate 3447

A new Webpack boilerplate with hot reloading React components, and error handling on module and component level.

amilajack/eslint-plugin-compat 2383

Lint the browser compatibility of your code

boltpkg/bolt 1651

⚡️ Super-powered JavaScript project management

gaearon/babel-plugin-react-transform 1099

Babel plugin to instrument React components with custom transforms

gaearon/react-transform-hmr 788

A React Transform that enables hot reloading React classes using Hot Module Replacement API

atlassian/jest-in-case 755

Jest utility for creating variations of the same test

avajs/ava-docs 431

Localized docs for AVA

atlassian/babel-plugin-react-flow-props-to-prop-types 233

Convert Flow React props annotation to PropTypes

babel-utils/babel-plugin-tester 191

Utilities for testing babel plugins

gaearon/react-transform-catch-errors 184

React Transform that catches errors inside React components

delete branch jamiebuilds/react-jeff

delete branch : dependabot/npm_and_yarn/lodash-4.17.15

delete time in 7 days

push eventjamiebuilds/react-jeff

dependabot[bot]

commit sha ef102012a02bb38d59f985e837d7982d36ed4b5e

Bump lodash from 4.17.11 to 4.17.15 (#6) Bumps [lodash](https://github.com/lodash/lodash) from 4.17.11 to 4.17.15. - [Release notes](https://github.com/lodash/lodash/releases) - [Commits](https://github.com/lodash/lodash/compare/4.17.11...4.17.15) Signed-off-by: dependabot[bot] <support@github.com>

view details

push time in 7 days

PR merged jamiebuilds/react-jeff

Bump lodash from 4.17.11 to 4.17.15 dependencies

Bumps lodash from 4.17.11 to 4.17.15. <details> <summary>Commits</summary>

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+3 -3

0 comment

1 changed file

dependabot[bot]

pr closed time in 7 days

delete branch jamiebuilds/react-jeff

delete branch : dependabot/npm_and_yarn/mixin-deep-1.3.2

delete time in 7 days

push eventjamiebuilds/react-jeff

dependabot[bot]

commit sha 0f1bf71da2e7ae1094110585cde97fbea94eb0e9

Bump mixin-deep from 1.3.1 to 1.3.2 (#5) Bumps [mixin-deep](https://github.com/jonschlinkert/mixin-deep) from 1.3.1 to 1.3.2. - [Release notes](https://github.com/jonschlinkert/mixin-deep/releases) - [Commits](https://github.com/jonschlinkert/mixin-deep/compare/1.3.1...1.3.2) Signed-off-by: dependabot[bot] <support@github.com>

view details

push time in 7 days

PR merged jamiebuilds/react-jeff

Bump mixin-deep from 1.3.1 to 1.3.2 dependencies

Bumps mixin-deep from 1.3.1 to 1.3.2. <details> <summary>Commits</summary>

  • 754f0c2 1.3.2
  • 90ee1fa ensure keys are valid when mixing in values
  • See full diff in compare view </details> <details> <summary>Maintainer changes</summary>

This version was pushed to npm by doowb, a new releaser for mixin-deep since your current version. </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+3 -3

0 comment

1 changed file

dependabot[bot]

pr closed time in 7 days

delete branch jamiebuilds/react-jeff

delete branch : dependabot/npm_and_yarn/safer-eval-1.3.5

delete time in 7 days

push eventjamiebuilds/react-jeff

dependabot[bot]

commit sha 8e6c095d2dd7159f704e983b5c60c3b1fcf0ac58

Bump safer-eval from 1.3.2 to 1.3.5 (#4) Bumps [safer-eval](https://github.com/commenthol/safer-eval) from 1.3.2 to 1.3.5. - [Release notes](https://github.com/commenthol/safer-eval/releases) - [Commits](https://github.com/commenthol/safer-eval/compare/v1.3.2...v1.3.5) Signed-off-by: dependabot[bot] <support@github.com>

view details

push time in 7 days

PR merged jamiebuilds/react-jeff

Bump safer-eval from 1.3.2 to 1.3.5 dependencies

Bumps safer-eval from 1.3.2 to 1.3.5. <details> <summary>Commits</summary>

  • 6d5ed4b 1.3.5
  • fbbc623 Merge pull request #7 from commenthol/strict-mode-recommendation
  • 1a87237 fix: use strict mode recommendation
  • b81dab9 1.3.4
  • 073267a Merge pull request #6 from commenthol/fix-breakout-console
  • 25c3048 docu: Update tested browsers/ node versions
  • 25fbbe5 fix: sandbox breakout with console.constructor...
  • 1ff9411 chore: bump dependencies
  • d3167c8 1.3.3
  • ba69286 Merge pull request #5 from commenthol/warning
  • Additional commits viewable in compare view </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot ignore this [patch|minor|major] version will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+33 -14

0 comment

1 changed file

dependabot[bot]

pr closed time in 7 days

delete branch jamiebuilds/light-sensor

delete branch : patch-1

delete time in 9 days

issue commentreact-spring/react-spring

v9.0.0-beta.34 • Feedback wanted

useTransition<Item, Props>() isn't as usable anymore:

// worked previously, now breaks
useTransition<Item, { value: number }>(item, null, {
  immediate: true,
  value: 0,
  from: { value: 1 },
  enter: { value: 0 },
  leave: { value: -1 },
  config: config.stuff,
})

// now:
useTransition<Item, { value: number } & UnknownProps & UseTransitionProps<Item>>(item, null, {
  immediate: true,
  value: 0,
  from: { value: 1 },
  enter: { value: 0 },
  leave: { value: -1 },
  config: config.stuff,
})

Before

https://github.com/react-spring/react-spring/blob/66087e18b64d6c6d5fd75f6d84e85ed59714769d/types/web.d.ts#L217-L225

After

https://github.com/react-spring/react-spring/blob/9c19e36b8c061b872ac563f1d5d9e99fab324096/packages/core/src/useTransition.d.ts#L22-L29

aleclarson

comment created time in 19 days

push eventjamiebuilds/jamie.build

Jamie Kyle

commit sha 65496fc25e0138545aa215e6c55f3f2df2509326

Update index.html

view details

push time in a month

pull request commentfacebook/react

Treat Namespace.use() as a React Hook

bump

jamiebuilds

comment created time in a month

issue commentfacebook/react

Feature request: renderTypes

Not suggesting that this API needs to be in React, but what about flipping the API around to validate it from the parent?

function isButton(element) {
  return true || false
}

function ButtonGroup({ children }) {
  return (
    <div className="btn-group">
      <Assert is={isButton}>{children}</Assert>
    </div>
  )
}
ljharb

comment created time in a month

issue openedreact-cosmos/rfcs

Cosmos Export Separate Documents

What's up?

In a CI environment I might want to run other tools against all (or some) of my fixtures. This might be something like visual regression tests or maybe some scripts written with Puppeteer to do smoke testing.

In those scenarios, I probably wouldn't care very much about the Cosmos UI itself, I'd just want to have statically built pages that I could use in other tools.

pages=$(cosmos-export --pages) # or some other flag, idk
# ./path/to/built/fixture.html
# ./path/to/other/built/fixture.html

for page in "${pages}"; do
   ./scripts/run-smoke-tests-on-page "${page}"
done

Mkay, tell me more...

This could potentially be extended by other tools out of the box:

cosmos-export --pages | cosmos-browser-visual-regressions
cosmos-export --pages | cosmos-etc

created time in a month

issue openedreact-cosmos/rfcs

Snapshots for manual/automated visual regression testing

What's up?

Snapshots are a really efficient way to tell if a fixture has changed from one commit to another. They are much faster than re-running an entire browser visual regression tool that requires diffing screenshots from real browsers.

However, looking at changes in snapshots is not a great experience. A lot of the time when snapshots have changed, it was intended. But that just makes it that much harder to catch when unintended changes have happened. Being able to actually visually see what the changes are is a much more reliable experience.

So what if we used snapshots for their performance, and the Cosmos UI + Browser-based visual regression tools for their feedback?

  1. Take snapshots of every fixture in a project
  2. Compare snapshots to discover which fixtures have "changed"
  3. Highlight fixtures that have "changed" in sidebar in the the Cosmos UI
  4. Allow the fixtures in the sidebar to be filtered down to just the ones that have "changed"
  5. Have a button in the UI to write the updated snapshot to the file system
  6. Allow the cosmos-export CLI to statically build just the fixtures that have "changed" between two commits (Useful for deploying on every PR)
  7. Have a library API/CLI command for listing all the fixtures that have "changed" so that other tooling can be run on just the fixtures that have "changed".

Mkay, tell me more...

cosmos-snapshot

Re-run all of the snapshots and list the ones that have changed vs the snapshots written to the file system.

$ cosmos-snapshot
/path/to/__fixtures__/foo.tsx

cosmos-snapshot --write

Same as cosmos-snapshot but write the changed snapshots back to the file system (similar to how prettier --write or jest -u works).

$ cosmos-snapshot --write
/path/to/__fixtures__/foo.tsx (updated)
cosmos-snapshot --since <git-ref>

Instead of comparing the snapshots against the file system, test them against a git ref.

$ cosmos-snapshot --since master
/path/to/__fixtures__/foo.tsx
/path/to/__fixtures__/bar.tsx
/path/to/__fixtures__/baz.tsx
Filters

On top of being able to filter fixtures by their name or path, you should also be able to filter by changed fixtures. Here's an idea for the query syntax:

@changed
@changed(since: <git-ref>)

Note: I think it's important this has a syntax so you can use it for CLI options like below.

cosmos-export --filter <query>

Instead of exporting every fixture, export only the fixtures matching a particular filter.

$ cosmos-export --filter "@changed(since: master)"
/path/to/__fixtures__/foo.tsx
/path/to/__fixtures__/bar.tsx
/path/to/__fixtures__/baz.tsx

Implementation Note: This should not rebuild every single fixture to re-snapshot them. It should be comparing the snapshots on the file system against the ones in the git ref. This will make the export process much faster so it can be run on every commit in a CI environment in even the biggest projects.

Snapshotting Quickly

I can see that Jest Snapshots are being used today. However, running jest is a rather heavyweight way of getting the Cosmos snapshots. It would be much faster if you used some of the libraries of either Jest or AVA to take the snapshots.

created time in a month

issue openedreact-cosmos/rfcs

View Source

What's up?

When statically deploying React Cosmos fixtures, it would be nice to be able to have a "View Source" button that displays the source code for the fixture within the Cosmos UI. This would make it a nicer tool for documenting component frameworks and such.

Mkay, tell me more...

Here's an example from the Atlaskit UI framework:

Screen Shot 2019-12-18 at 4 37 38 PM

Users of the documentation can look at code examples right next to the rendered version of the code.

But behind the scenes this is not the raw source code, it's actually be slightly preprocessed so that the imports are rewritten to be package names instead of relative paths.

- import Badge from "../src/index.tsx"
+ import Badge from "@atlaskit/badge"

So it would be good to provide some sort of hook to allow for arbitrary preprocessing of the source file.

created time in a month

issue openedjamiebuilds/workspaces-run

Flag for splitting across CI nodes

Using https://github.com/jamiebuilds/ci-parallel-vars

Bolt has bolt workspaces run --parallel-nodes

created time in a month

push eventjamiebuilds/the-super-tiny-compiler

Johnny Peck

commit sha d8d40130459d1537f6117a927947cd46c83182b0

Update the-super-tiny-compiler.js Plural "node"

view details

push time in a month

startedjamiebuilds/workspaces-run

started time in a month

issue commenttc39/proposal-generator-arrow-functions

Syntax

Even if you're returning some sort of op codes via yield you'd still have a loop at the top-level somewhere which receives the next op code and resumes. Here's another quickly thrown together example: https://gist.github.com/jamiebuilds/86eb0b64bd4a18950307211cf8297fb0

chicoxyzzy

comment created time in a month

created tagjamiebuilds/workspaces-run

tagv1.0.1

Run tasks/scripts across Yarn/Lerna/Bolt/etc workspaces.

created time in a month

push eventjamiebuilds/workspaces-run

Jamie Kyle

commit sha 5ab7f263d75ffadde9cd63f9ae5f9a75ec044674

Fix bin entry

view details

Jamie Kyle

commit sha c3fa2d215a247a41946f579671ded5687f58f445

1.0.1

view details

push time in a month

created tagjamiebuilds/workspaces-run

tagv1.0.0

Run tasks/scripts across Yarn/Lerna/Bolt/etc workspaces.

created time in a month

push eventjamiebuilds/workspaces-run

Jamie Kyle

commit sha 2dd1ccc7f31235060536117f58d3e859326d84c1

1.0.0

view details

push time in a month

push eventjamiebuilds/workspaces-run

Jamie Kyle

commit sha 6391cd3efd8429ea6f195aac56b1716f9b80d8ed

init commit

view details

push time in a month

create barnchjamiebuilds/workspaces-run

branch : master

created branch time in a month

created repositoryjamiebuilds/workspaces-run

Run tasks/scripts across Yarn/Lerna/Bolt/etc workspaces.

created time in a month

issue commenttc39/proposal-generator-arrow-functions

Syntax

I'm sure you understand this already, but here's an example of using an iterator for recursive descent with a generator function: https://gist.github.com/jamiebuilds/7322021dd6584ef7d2cbd08cd637d683

chicoxyzzy

comment created time in 2 months

issue commenttc39/proposal-generator-arrow-functions

Syntax

Yes, although fair point that calling a generator function is not completely unobservable without calling .next() (but that's well within the realm of edge cases).

Such generators may satisfy the definition of iterator, but they usually won’t actually work as iterators, because they typically expect values to be received through next(), unlike generators intending to be used for iteration, which ignore these arguments.

I'm not sure what you mean. Even if you are calling .next() directly without an argument or using the return value, you're still using the iterator interface, and I'm not sure I've seen any usage of generators that doesn't involve a loop (while (!done), recursion, etc) around .next() so any real-world use case will still resemble an "iterator" in the abstract.

chicoxyzzy

comment created time in 2 months

issue commenttc39/proposal-generator-arrow-functions

Syntax

given that the syntax is async function but it returns a Promise

I'd also throw out there that async functions can be used without "using" promises, but generators cannot be used without using iterators:

async function main() { ... }
main() // will execute the entire function as it is written and many node programs do just this

function *iter() { ... }
iter() // never executes the function body, and there's no reason to do this.
chicoxyzzy

comment created time in 2 months

issue commenttc39/proposal-generator-arrow-functions

Syntax

A generator is a pauseable (synchronous) function.

Neither description is technically incorrect, but they miss the important detail that they always generate an iterator/iterable, and using the iterator protocol is the only way that you can use them. Also, I think that you'd find that "value generator" is somewhat meaningless when trying to explain generators to developers (most functions "generate" "values").

chicoxyzzy

comment created time in 2 months

issue commenttc39/proposal-generator-arrow-functions

Syntax

Maybe, but as it stands right now the relationship isn't seen by many. Anecdotally, I've talked to developers who describe generators as "pausable functions" (not sure where this comes from) or "how async functions are implemented under the hood" (which I think comes from transpilers), and I've seen them use the iterator protocol directly with while loops and calling .next() instead of using for..of. I suspect generators are underutilized (not that they are something every developer would use daily) for this reason.

chicoxyzzy

comment created time in 2 months

issue commenttc39/proposal-generator-arrow-functions

Syntax

Does the keyword option have to be a variant on the word generator?

When teaching them, the word "Generators" has caused a lot of confusion in how they relate to "Iterators". So I started referring to them as "Iterators and Iterator Functions" and that seemed to help people understand their relationship.

So I think iterator could be a good alternative choice for a keyword.

But even better than that: "Iter" is already a well-established abbreviation for "Iterator" so the keyword iter could work:

iter function fn() {...}
async iter function fn() {...}
chicoxyzzy

comment created time in 2 months

delete branch jamiebuilds/modern-normalize

delete branch : patch-1

delete time in 2 months

issue commentreact-cosmos/react-cosmos

Cosmos Export Separate Documents

Hmm... I think it would be better to have something even more "pure" than that, where it's just static HTML pages with "no" runtime (short of rendering the component with ReactDOM.render()) or routing logic.

<!doctype html>
<html>
  <body>
     <div id="root"></div>
     <script src="./path/to/fixture-entry-point.js"></script>
  </body>
</html>

The benefit is that you can write scripts with tools like Puppeteer without having to be concerned with any implementation details of how Cosmos works. If you want to select an element, you just query for it, you don't have to select the iframe and enter its context or anything.

It would also be nice if these separate HTML files pointed to separate entry points for each different fixtures so that loading one fixture didn't load all of them. This makes the pages load faster, and also makes it faster to parallelize work on different fixtures in scripts.

jamiebuilds

comment created time in 2 months

issue commentreact-cosmos/react-cosmos

Website Feedback

If you want to put the docs in markdown, you could also drop them all into a docs/ folder that can be used to generate the website. I think it would be a pretty significant improvement

jamiebuilds

comment created time in 2 months

issue openedreact-cosmos/react-cosmos

Cosmos Export Separate Documents

What's up?

In a CI environment I might want to run other tools against all (or some) of my fixtures. This might be something like visual regression tests or maybe some scripts written with Puppeteer to do smoke testing.

In those scenarios, I probably wouldn't care very much about the Cosmos UI itself, I'd just want to have statically built pages that I could use in other tools.

pages=$(cosmos-export --pages) # or some other flag, idk
# ./path/to/built/fixture.html
# ./path/to/other/built/fixture.html

for page in "${pages}"; do
   ./scripts/run-smoke-tests-on-page "${page}"
done

Mkay, tell me more...

This could potentially be extended by other tools out of the box:

cosmos-export --pages | cosmos-browser-visual-regressions
cosmos-export --pages | cosmos-etc

created time in 2 months

issue openedreact-cosmos/react-cosmos

Website Feedback

I thought I'd give some feedback on how the https://reactcosmos.org could be better, I'm happy to help with some of these items, but better to write them down and discuss them first.

  • The website works really well as a marketing site right now, but it doesn't really capitalize on that by calling users to action. It should tell them to "Get Started" or "Install" with either a big button to some docs or with a CLI command they can run to get going (maybe even both)
  • The website also doesn't really help people who are looking for docs. Linking to "GitHub" is a good start, but it's not my first choice when looking for a nicer documentation experience. It would be great if the website had full documentation, but even just having a "Documentation" link that sends you to the README would be better.
  • Design-wise the site is beautiful, but the scroll animations are a bit annoying when you're trying to find something quickly on the page. Firing the animations once on the way down is okay (and maybe making them a little bit shorter time-wise and more subtle), but they should be mostly static after that. It would also be great if the site respected prefers-reduced-motion as some users like myself get slightly nauseous when there's lots of animation.
  • One of the biggest things that I've found drives adoption of open source projects is finding out that a bunch of bigger companies use the project too. Early on in Babel when I introduced the babeljs.io/users page, it quickly became one of the highest traffic pages. When people see names like Facebook, Netflix, Mozilla, etc., they feel like the project has been well vetted already. You might not even realize how many big companies are using your project until you start asking for them to tell you.
  • If possible, it would be great if you could find a way to embed Cosmos itself onto the homepage, even if it is just iframed in. Especially if you could use something like https://react-joyride.com to guide them through all the different features.
  • Alternatively, the homepage could use more screenshots demoing the functionality of Cosmos. People like to see what you are talking about more than they like reading about it.
  • The Benefits section are good points, but some of them may not be obvious to users and they may want additional information. It would be great to have some sort of subtext that drives each point home and puts them in context.
  • "React Cosmos can be used in powerful ways. Snapshot and visual regression tests are possible [...]" this sounds like a roundabout way of telling people they have to do work to set it up. So for starters, you should try to make both of these really really easy to setup, and second you should emphasize how easy it is to setup. Also "Open Platform" is kinda a bold claim that sounds like marketing, it would be better to say something like "Extensible"
  • I appreciate that you don't bother mentioning Storybook on the website. A lot of users will ask you for that comparison, but it'll only do one of two things: Make the project seem bitter about Storybook, or make it seem like the benefits aren't all that significant. It's much better to focus on making your users so happy they spread the word for you. Focus on what makes Cosmos an amazing tool and the rest really does follow. That being said, you should have something to say to people when they ask you what the difference is from Storybook. I would again focus on the experience of Cosmos over Storybook, and how you're a much more focused project with just React support (for now?) and you're being very detail oriented.
  • I also just want to put out there that I think it's important that the website has all of the docs on how to use Cosmos. READMEs don't drive nearly as much adoption as websites, and even really well done docs on GitHub don't have the same impact as a website with even poorly done docs. People will say the project isn't well documented if the site doesn't contain lots of documentation.

Sorry if this was too much of a brain dump. I've worked on a lot of marketing sites for projects like Babel, Yarn, and Flow so I have a lot of strong opinions. You've done a great job already though :)

created time in 2 months

issue openedreact-cosmos/react-cosmos

Snapshots for manual/automated visual regression testing

What's up?

Snapshots are a really efficient way to tell if a fixture has changed from one commit to another. They are much faster than re-running an entire browser visual regression tool that requires diffing screenshots from real browsers.

However, looking at changes in snapshots is not a great experience. A lot of the time when snapshots have changed, it was intended. But that just makes it that much harder to catch when unintended changes have happened. Being able to actually visually see what the changes are is a much more reliable experience.

So what if we used snapshots for their performance, and the Cosmos UI + Browser-based visual regression tools for their feedback?

  1. Take snapshots of every fixture in a project
  2. Compare snapshots to discover which fixtures have "changed"
  3. Highlight fixtures that have "changed" in sidebar in the the Cosmos UI
  4. Allow the fixtures in the sidebar to be filtered down to just the ones that have "changed"
  5. Have a button in the UI to write the updated snapshot to the file system
  6. Allow the cosmos-export CLI to statically build just the fixtures that have "changed" between two commits (Useful for deploying on every PR)
  7. Have a library API/CLI command for listing all the fixtures that have "changed" so that other tooling can be run on just the fixtures that have "changed".

Mkay, tell me more...

cosmos-snapshot

Re-run all of the snapshots and list the ones that have changed vs the snapshots written to the file system.

$ cosmos-snapshot
/path/to/__fixtures__/foo.tsx

cosmos-snapshot --write

Same as cosmos-snapshot but write the changed snapshots back to the file system (similar to how prettier --write or jest -u works).

$ cosmos-snapshot --write
/path/to/__fixtures__/foo.tsx (updated)
cosmos-snapshot --since <git-ref>

Instead of comparing the snapshots against the file system, test them against a git ref.

$ cosmos-snapshot --since master
/path/to/__fixtures__/foo.tsx
/path/to/__fixtures__/bar.tsx
/path/to/__fixtures__/baz.tsx
Filters

On top of being able to filter fixtures by their name or path, you should also be able to filter by changed fixtures. Here's an idea for the query syntax:

@changed
@changed(since: <git-ref>)

Note: I think it's important this has a syntax so you can use it for CLI options like below.

cosmos-export --filter <query>

Instead of exporting every fixture, export only the fixtures matching a particular filter.

$ cosmos-export --filter "@changed(since: master)"
/path/to/__fixtures__/foo.tsx
/path/to/__fixtures__/bar.tsx
/path/to/__fixtures__/baz.tsx

Implementation Note: This should not rebuild every single fixture to re-snapshot them. It should be comparing the snapshots on the file system against the ones in the git ref. This will make the export process much faster so it can be run on every commit in a CI environment in even the biggest projects.

Snapshotting Quickly

I can see that Jest Snapshots are being used today. However, running jest is a rather heavyweight way of getting the Cosmos snapshots. It would be much faster if you used some of the libraries of either Jest or AVA to take the snapshots.

created time in 2 months

issue commentreact-cosmos/react-cosmos

Edit in CodeSandbox button

There is already a tool called codesandboxer that does this (See Docs)

You can see it in action on the Atlaskit website (Up in the top-right corner with the CodeSandbox logo).

umidbekkarimov

comment created time in 2 months

issue openedreact-cosmos/react-cosmos

View Source

What's up?

When statically deploying React Cosmos fixtures, it would be nice to be able to have a "View Source" button that displays the source code for the fixture within the Cosmos UI. This would make it a nicer tool for documenting component frameworks and such.

Mkay, tell me more...

Here's an example from the Atlaskit UI framework:

Screen Shot 2019-12-18 at 4 37 38 PM

Users of the documentation can look at code examples right next to the rendered version of the code.

But behind the scenes this is not the raw source code, it's actually be slightly preprocessed so that the imports are rewritten to be package names instead of relative paths.

- import Badge from "../src/index.tsx"
+ import Badge from "@atlaskit/badge"

So it would be good to provide some sort of hook to allow for arbitrary preprocessing of the source file.

created time in 2 months

created tagjamiebuilds/is-mergeable

tagv1.1.1

Check if a GitHub Pull Request is in a (most likely) mergeable state

created time in 2 months

push eventjamiebuilds/is-mergeable

Jamie Kyle

commit sha a2e22092265e1d783e5678a8f5c634fdd2321efa

Ignore review comments

view details

Jamie Kyle

commit sha b914c900670d5823a311a4f0551552e7a362a515

1.1.1

view details

push time in 2 months

create barnchparcel-bundler/website

branch : update-package-name

created branch time in 2 months

issue commentmicrosoft/TypeScript

callbacks should select the right overload

Here is the simplest possible replication of this I could come up with: [Playground]

interface Callback {
  (value: number): any
  (value: string): any
}

function fn(callback: Callback) {
  // ...
}

fn(value => {
  // ^ Parameter 'value' implicitly has an 'any' type.
})

<details> <summary>Here is a real world example: [<a href="https://www.typescriptlang.org/play/index.html#code/JYOwLgpgTgZghgYwgAgMJwDYYEaINYA8AKgHzIDeAUMjcgBTRQD2UAXMiAK5YA0yUEAM7cw7IgEp2nEHhBMA7iGq0GUZm2QBRNSz4DhGUR24ZJyabIVKAvpUqhIsRCiJxBhUhWU06CTDnx2dCxcBA8SMws5RUpbSggADwAHFjBkGGkEMGAmEGRBaGAhYhI6MDc8QTEKkoBtAF0+PxDAtH9QjwaI9gA3JmAAEy8ASAwINNABxOQAXmQABkpR8f4hESrkIgbZ5Aa7YYyQLJy8kESwOnER5bTy9x27ytrJxPrkAB934yxvWhpgGD0ACEjyuVGGEOaATCdC4vFWBjAgnES2G1mQEAwBWuw0edFU6j0a0MVxmZHBEOGAPojBYYNRlKhHQJum+pgZaIxWJQFMp+nWADokpxBAALOj8kkc4ZnBIXFGUtEM6wKpVKpay+WxOwFKBFQR0Ja1VEIbCzMgFMBEYAAWwgTE4F0u5uQpthJj4AEZxHwAMzzeY+k1msn5cbWu0Op2kshuuEYPgAJh9yETAaDkJDFvDtvtjvxMdd2Hd8N9Kc96Z4S0aSxZUCJiORLop1Lr9MZuUETDGAtpUDbqPRmOxvIQne7EAFGCYAHMJcSkarbGiq+IgA">Playground</a>] </summary>

interface Callback<T> {
  (error: null, result: T): unknown
  (error: Error, result: null): unknown
}

interface Task<T> {
  (callback: Callback<T>): unknown
}

export function series<T>(tasks: Task<T>[], callback: Callback<T[]>): void {
  let index = 0
  let results: T[] = []

  function next() {
    let task = tasks[index]
    if (!task) {
      callback(null, results)
    } else {
      task((error, result) => {
        //  ^ Parameter 'error' implicitly has an 'any' type.
        //         ^ Parameter 'results' implicitly has an 'any' type.
        if (error) {
          callback(error, null)
        } else {
          results.push(result)
          next()
        }
      })
    }
  }
  next()
}

series([
  cb => setTimeout(() => cb(null, 1), 300),
  cb => setTimeout(() => cb(null, 2), 200),
  cb => setTimeout(() => cb(null, 3), 100),
], (error, results) => {
  // ^ Parameter 'error' implicitly has an 'any' type.
  //       ^ Parameter 'results' implicitly has an 'any' type.
  if (error) {
    console.error(error)
  } else {
    console.log(results)
  }
})

</details>

pirix-gh

comment created time in 2 months

push eventjamiebuilds/task-graph-runner

Jamie Kyle

commit sha 15ea33b80454c4a4f537fbd4e80288032c4e2404

1.0.3

view details

push time in 2 months

created tagjamiebuilds/task-graph-runner

tagv1.0.3

Run async tasks with dependencies

created time in 2 months

push eventjamiebuilds/task-graph-runner

Michael Blaszczyk

commit sha 1845e55d7c73eb2ba292118c0688e74a8af90866

Fix return type of task

view details

Jamie Kyle

commit sha 98c345779a16dab589ccaae858fbddcb74a1ce4a

Merge pull request #1 from Blasz/fix-type Fix return type of task

view details

push time in 2 months

issue openedmicrosoft/TypeScript-Website

v2 Layout issue in Firefox, causing horizontal scroll

This element is going off the page and causing horizontal scrolling on Firefox 71.0

Screen Shot 2019-12-06 at 10 41 12 AM

created time in 2 months

release jamiebuilds/chunkd

v2.0.1

released time in 2 months

push eventjamiebuilds/chunkd

Jamie Kyle

commit sha 171b682049b170df10e3391d7b1b8a35c34f4d69

2.0.1

view details

push time in 2 months

created tagjamiebuilds/chunkd

tagv2.0.1

Get a chunk of an array based on the total number of chunks and current index

created time in 2 months

delete branch jamiebuilds/chunkd

delete branch : add-dist-files

delete time in 2 months

push eventjamiebuilds/chunkd

Jamie Kyle

commit sha d35b84d7def1665242c147d1d545a72803a46933

Add all dist files to published package (#8)

view details

push time in 2 months

PR opened jamiebuilds/chunkd

Add all dist files to published package
+1 -1

0 comment

1 changed file

pr created time in 2 months

create barnchjamiebuilds/chunkd

branch : add-dist-files

created branch time in 2 months

issue openeddrop-ice/dear-github-2.0

Dear GitHub org

I own the original dear-github org. I just wanted to let you know that I added a bunch of links from that org to this letter.

I also wanted to offer adding the maintainers of this letter to the original org and open it up in case you wanted the repository to live there. I don't know if that would be good for SEO at all or not. But just an offer.

created time in 3 months

push eventdear-github/dear-github

Jamie Kyle

commit sha 00ef14e95fb4eeb2b6067c4c7c492306c8af8043

Update README.md

view details

push time in 3 months

push eventdear-github/dear-github-2.0

Jamie Kyle

commit sha 534a5578f5f2556a962fa336730fa9420af548b9

Update README.md

view details

push time in 3 months

starteddrop-ice/dear-github-2.0

started time in 3 months

PR opened drop-ice/dear-github-2.0

Reviewers
Signed @jamiebuilds
+1 -0

0 comment

1 changed file

pr created time in 3 months

push eventjamiebuilds/dear-github-2.0

Jamie Kyle

commit sha ddb32bfa4a41613897471d77249844bc2c435fa5

Signed @jamiebuilds

view details

push time in 3 months

fork jamiebuilds/dear-github-2.0

📨 An open letter to GitHub from the maintainers of open source projects

fork in 3 months

push eventjamiebuilds/scritch

Dario Vladović

commit sha 134623ce5e01d78d37b3817bea0db25f027c5c28

Modify `package.json` (#5) - fixing homepage and bugs url - sorting fields using `sort-package-json` - adding `files` field

view details

push time in 3 months

PR merged jamiebuilds/scritch

Modify `package.json`

This PR brings in following changes:

  • fixing homepage and bugs url
  • sorting fields using sort-package-json
  • adding files field
+21 -18

0 comment

1 changed file

vladimyr

pr closed time in 3 months

issue commentavajs/ava

Support nested groups?

Length of code correlates to readability, which correlates to maintainability.

Length does not correlate to readability or maintainability, or Regex would be known as the most readable and maintainable language ever created.

Code readability is hard to quantify, but there are some traits that definitely correlate to readability much stronger than "length".

Something we can learn from interface design is the value of putting related information physically closer together and visually distinct from unrelated information.

Here's a recent notable example that came from Jira's redesign (GIF is kinda slow, wait for it):

New-Jira-Issue

[Source]

Code benefits from this in the same way, a recent notable example is the redesign of UI logic in React from a class-based structure to "Hooks":

DqsCilOU0AAoS7P

[Source]

BDD-style describe() blocks with state that gets built-up inside beforeEach() blocks leads to the "steps" of the test to be split up and spread all around your test suite.


And for the record, creating setupX() functions is often more DRY than creating beforeEach() blocks, I have done this exact refactor on code bases with thousands of tests, and greatly reduced repetition as a result. For example:

describe("one", () => {
  let a, b, c
  beforeEach(() => {
    a = new A({
      a: "whole",
      bunch: "of",
      code: "to",
      setup: "a",
    })
    b = new B({
      a: "whole",
      bunch: "of",
      code: "to",
      setup: "b",
    })
    c = new C({
      a: "whole",
      bunch: "of",
      code: "to",
      setup: "c",
    })
  })

  test("example 1", () => {
    // ...
  })
})

describe("two", () => {
  let a, b, c
  beforeEach(() => {
    a = new A({
      a: "whole",
      bunch: "of",
      code: "to",
      setup: "a",
      slightly: "different",
    })
    b = new B({
      a: "whole",
      bunch: "of",
      code: "to",
      setup: "b",
      slightly: "different",
    })
    c = new C({
      a: "whole",
      bunch: "of",
      code: "to",
      setup: "c",
      slightly: "different",
    })
  })

  test("example 2", () => {
    // ...
  })
})

describe("three", () => {
  let a, b, c
  beforeEach(() => {
    a = new A({
      a: "whole",
      bunch: "of",
      code: "to",
      setup: "a",
      yet: "another way",
    })
    b = new B({
      a: "whole",
      bunch: "of",
      code: "to",
      setup: "b",
      yet: "another way",
    })
    c = new C({
      a: "whole",
      bunch: "of",
      code: "to",
      setup: "c",
      yet: "another way",
    })
  })

  test("example 3", () => {
    // ...
  })
})

And JavaScript's answer on how to solve this is to pull some of that setup code into reusable functions... just like the setupX() functions I've recommended.

function setupA(opts = {}) {
  return new A({
    a: "whole",
    bunch: "of",
    code: "to",
    setup: "a",
    ...opts,
  })
}

let a1 = setupA()
let a2 = setupA({ slightly: "different" })
let a3 = setupA({ yet: "another way" })

thanos-i-am-inevitable.gif

Also what's this nonsense acting like "DRY" is "old school" lol

novemberborn

comment created time in 3 months

push eventjamiebuilds/is-mergeable

Jamie Kyle

commit sha 265b0b66cdae8918d740f54da171a23e51d4ece6

1.1.0

view details

push time in 3 months

created tagjamiebuilds/is-mergeable

tagv1.1.0

Check if a GitHub Pull Request is in a (most likely) mergeable state

created time in 3 months

push eventjamiebuilds/is-mergeable

Jamie Kyle

commit sha d9730ebc26599214cc3ff4cce56ca69fd4a27c2f

Add --ignore-git-mergeability flag

view details

push time in 3 months

delete branch jamiebuilds/chunkd

delete branch : remove-publish-gpr

delete time in 3 months

push eventjamiebuilds/chunkd

Jamie Kyle

commit sha a72f2ce70c7c1020a5ac689aeb11ae8212b83cab

Remove publish to GPR (#7)

view details

push time in 3 months

PR merged jamiebuilds/chunkd

Remove publish to GPR

This package can't be published to GitHub Package Registry because it isn't scoped to my username.

+0 -15

0 comment

1 changed file

jamiebuilds

pr closed time in 3 months

PR opened jamiebuilds/chunkd

Remove publish to GPR

This package can't be published to GitHub Package Registry because it isn't scoped to my username.

+0 -15

0 comment

1 changed file

pr created time in 3 months

create barnchjamiebuilds/chunkd

branch : remove-publish-gpr

created branch time in 3 months

release jamiebuilds/chunkd

v2.0.0

released time in 3 months

delete branch jamiebuilds/chunkd

delete branch : publish-v2

delete time in 3 months

push eventjamiebuilds/chunkd

Jamie Kyle

commit sha e6505c2df612fb284849320f5213ab79b1cc4378

2.0.0 (#6)

view details

push time in 3 months

PR merged jamiebuilds/chunkd

2.0.0
+2 -2

0 comment

2 changed files

jamiebuilds

pr closed time in 3 months

PR opened jamiebuilds/chunkd

2.0.0
+2 -2

0 comment

2 changed files

pr created time in 3 months

create barnchjamiebuilds/chunkd

branch : publish-v2

created branch time in 3 months

created tagjamiebuilds/chunkd

tagv2.0.0

Get a chunk of an array based on the total number of chunks and current index

created time in 3 months

delete branch jamiebuilds/chunkd

delete branch : v2

delete time in 3 months

push eventjamiebuilds/chunkd

Jamie Kyle

commit sha cd074013adab45290c548f48184e005cab835fb0

Migrate to TypeScript/GitHub Actions (#5) * Migrate to TypeScript/GitHub Actions * Move workflows to correct directory

view details

push time in 3 months

PR merged jamiebuilds/chunkd

Migrate to TypeScript/GitHub Actions
+4841 -3685

0 comment

16 changed files

jamiebuilds

pr closed time in 3 months

push eventjamiebuilds/chunkd

Jamie Kyle

commit sha 70fa81148e4f2265512cc8fb9e003413a5d34168

Move workflows to correct directory

view details

push time in 3 months

PR opened jamiebuilds/chunkd

Migrate to TypeScript/GitHub Actions
+4841 -3685

0 comment

16 changed files

pr created time in 3 months

create barnchjamiebuilds/chunkd

branch : v2

created branch time in 3 months

created tagjamiebuilds/is-mergeable

tagv1.0.2

Check if a GitHub Pull Request is in a (most likely) mergeable state

created time in 3 months

push eventjamiebuilds/is-mergeable

Jamie Kyle

commit sha a75333bfc3050755014388125fa38b4ef37cb3f6

support COMMENTED review.state

view details

Jamie Kyle

commit sha f39893481797ee9124046221358f4614c5798662

1.0.2

view details

push time in 3 months

fork jamiebuilds/changesets

🦋 A way to manage your versioning and changelogs with a focus on multi-package repositories

fork in 3 months

PR closed jamiebuilds/the-super-tiny-compiler

style: prefer const over let

Replace let with const where possible. This is obviously a nitty style preference, but I like to use const where possible so that it's clear on first glance what will be reassigned

+12 -12

2 comments

1 changed file

AriLFrankel

pr closed time in 4 months

pull request commentjamiebuilds/the-super-tiny-compiler

style: prefer const over let

Yeah no, please don’t make style PRs on a repo that is not yours. I promise you every maintainer in existence will be annoyed about it. Also const is a pointless language feature and never should have been added to JS

AriLFrankel

comment created time in 4 months

issue commentparcel-bundler/parcel

RFC: Default ServiceWorker to avoid cascading invalidation

Also unfortunately, especially in the namer case, it's hard to extend the default behavior - you'd have to rewrite the whole namer.

Could we expose parts of it as a library?

devongovett

comment created time in 4 months

push eventjamiebuilds/jamie.build

Jamie Kyle

commit sha 4a558ee20a20c313c26ed52dd7225a4e46fdc0d4

Update index.html

view details

push time in 4 months

more