AndersDJohnson
Repos
759
Followers
192
Following
525

Find dependencies to transpile with Babel.

130
3

:mag: Zoom responsively, images & more, w/ jQuery.

164
47

Force users to use yarn instead of npm.

50
6

Get multiple pages from paginated APIs with fetch.

21
2

⚛️😎⚛️ Connect to Redux state with GraphQL query client-side via React Hook.

⚛️🚧🐐 Mock React components to noops with Jest. Shallow rendering for RTL.

Events

AndersDJohnson delete branch patch-1
Created at 8 hours ago
fix(eslint-utils): allow no default options

PR Checklist

Overview

Created at 8 hours ago

Update RuleCreator.test.ts

Created at 15 hours ago

handle defaultOptions fallback inline

Created at 15 hours ago
fix(eslint-utils): allow no default options

PR Checklist

Overview

Created at 19 hours ago

fix(eslint-utils): allow no default options

Created at 19 hours ago
feat: no-danger find props on all components (not just native)

@ljharb That could be useful! I think we would still want to support a simple boolean, for projects that want to cover everything and not have to maintain a list, especially as new styled-components may be created often. But if we wanted, we could support optionally passing a string array of component names (instead of a boolean) to scope it more specifically.

Created at 1 day ago
feat: no-danger find props on all components (not just native)

@ljharb Exactly! Thanks for re-opening. I think that's it - just one generic boolean option to target custom components / non-native JSX tags. I'd be willing to try to raise a PR to implement if I have time soon.

Created at 1 day ago
feat: no-danger find props on all components (not just native)

@ljharb I think it's mostly relevant how styled-components are consumed, which is just like regular components, which are easy to target the way this rule is already doing.

Created at 1 day ago
AndersDJohnson delete branch tokens
Created at 3 days ago
pull request closed
feat: identifiers

Supports https://github.com/dependents/node-dependency-tree/issues/147.

Support passing an option identifiers: true to return imported identifiers in addition to paths.

For named imports or re-exports like this:

import { one, two } from 'whatever';

// or

export { one, two } from 'whatever';

The result will then look like this:

[
  { path: 'whatever', identifiers: ['one', 'two'] }
]

instead of just this:

['whatever']

In the case of default exports like:

import foo from 'whatever';

We'll return:

{ path: 'whatever', identifiers: ['default'] }

In cases of import or re-export all, or dynamic imports, or where we otherwise just can't determine, like:

import * from 'whatever';

// or

export * from 'whatever';

// or

import('whatever').then(/* ... */);

We'll return:

{ path: 'whatever', identifiers: ['*'] }
Created at 3 days ago
feat: identifiers

closing since upstream issue https://github.com/dependents/node-dependency-tree/issues/147 was closed, to be replaced by https://github.com/dependents/detective-typescript/pull/48 perhaps

Created at 3 days ago
AndersDJohnson delete branch patch-2
Created at 3 days ago
feat: no-danger find props on all components (not just native)

@ljharb Understood. I think it would be a simple change to add an option to not run the jsxUtil.isDOMComponent(node.parent) check. But if there's no appetite for that, yes we can create a separate rule as a fork or whatever. Thanks for the discussion.

Created at 3 days ago
AndersDJohnson delete branch patch-1
Created at 3 days ago
docs: add eslint-interactive reference to README
Created at 3 days ago
AndersDJohnson create branch docs-eslint-interactive
Created at 3 days ago
pull request opened
docs: fix subtrees typo in README

Sorry if annoying! Just noticed a minor typo in the README. Good to make sure the docs are as clear as possible. Thanks!

Created at 3 days ago

docs: fix subtrees typo in README

Created at 3 days ago
Created at 3 days ago
feat: no-danger find props on all components (not just native)

@ljharb You're totally right - a custom component could remove a dangerous prop. That's a good suggestion.

In practice, though, that's not already going to be in place, and may not be as feasible to roll out to large existing code bases, and especially not to roll out to existing 3rd party libraries where this may not be a proper assumption to bake-in, including older versions that consuming applications may be locked into and prevented from upgrading for now.

A side note, but I have something of a general philosophy around linting and tooling in general - and tend to believe that if it's going to be most effective and useful then it needs to support rolling out suggested patterns to existing code bases more incrementally, where lint tooling maintainers understand that some things cannot practically be fixed right away.

Anyway, the biggest practical example I have right now is styled-components (https://styled-components.com/docs/basics#getting-started):

import styled from 'styled-components';

// Create a Title component that'll render an <h1> tag with some styles
const Title = styled.h1`
  font-size: 1.5em;
  text-align: center;
  color: palevioletred;
`;

// ...

<Title dangerouslySetInnerHTML={{
  __html: '<span>Hello!</span>'
}} />

Example on CodeSandbox: https://codesandbox.io/s/styled-components-dangerous-26ugid

Here you can immediately see how, although Title doesn't look like a native element syntactically (and according to ESLint AST), it still behaves almost exactly like one (other than the addition of styling - implicit className, etc.). All native element props are made available on the styled wrapper and forwarded to the native element, including dangerouslySetInnerHTML.

But critically, in this case, we're not protected by the react/no-danger lint rule against using dangerouslySetInnerHTML, because the rule today doesn't support detecting that prop on non-native elements, to my knowledge.

I don't know that styled-components would be able to support removing (or not forwarding) dangerouslySetInnerHTML as a general default, since I'm sure there are applications with different preferences or requirements that need to retain this behavior. Perhaps there would be a way for them to add a configuration option to control this, but I'm not sure that's the best approach.

So, I'm proposing a simple option to opt-in (or perhaps out) of having react/no-danger apply to non-native elements, too.

E.g.:

`.eslint

{
  "react/no-danger": ["error", {
    includeNonDOMElements: true
  }],
}

I'm happy to look into contributing an implementation, if the maintainers and/or community agree this would be a useful feature.

Created at 4 days ago
issue comment
Updated link in readme to reflect correct website (TLD)

@kelvinelove Agreed! I had noticed as well, and submitted https://github.com/webpack/analyse/pull/81, until I found your PR and closed mine. Wondering if this project is still maintained?

Created at 4 days ago
delete branch
AndersDJohnson delete branch patch-2
Created at 4 days ago
pull request closed
docs: fix github pages link in readme

Should the GitHub pages link in the README point to github.io instead of github.com? And also be HTTPS. E.g., https://webpack.github.io/analyse instead of http://webpack.github.com/analyse

A maintainer/admin could also update the website link in the repository metadata.

Created at 4 days ago
issue comment
docs: fix github pages link in readme

Looks like this is a duplicate of https://github.com/webpack/analyse/pull/75 (at least).

Is this project still maintained?

Created at 4 days ago
pull request opened
docs: fix github pages link in readme

Should the GitHub pages link in the README point to github.io instead of github.com? And also be HTTPS. E.g., https://webpack.github.io/analyse instead of http://webpack.github.com/analyse

A maintainer/admin could also update the website link in the repository metadata.

Created at 4 days ago