profile
viewpoint
Jasmine Xie jasminexie Beijing, China https://jasminexie.github.io Junior front-end with some experience in Angular, Vue, automated testing and CI/CD.

jasminexie/100-days-css 12

100 Days of CSS challenge with Parcel, PostCSS and Pug.

jasminexie/seleniumgrid-pytest 2

Quickstart project for automated testing in Python with Pytest and Selenium Grid

jasminexie/adhoc-color-picker 1

Color picker for Adhoc, adapted from ngx-color-picker

jasminexie/github-plugin-i18n-upgrade 1

Upgraded i18n for gitbook

jasminexie/raven-weapp 1

Sentry SDK for WeApp

jasminexie/angular2-color-picker 0

Angular 2 Color Picker Directive, no dependences required.

jasminexie/babel-rollup-boilerplate 0

Minimal boilerplate for Javascript Libraries, using: babel@7.4, rollup@1.11

jasminexie/biggreensnake 0

My tech blog and other miscellaneous things. Under development!

jasminexie/calcy 0

React Based Calculator App with Dark Mode

issue commentgajus/eslint-plugin-jsdoc

Place auto-generated JSDoc comments above decorators/annotations

@david-sharer : No guarantees of being able to get to it, but please feel a new report so it is not lost.

seanblonien

comment created time in 8 hours

pull request commentgajus/eslint-plugin-jsdoc

Fix check line alignment

@renatho : I really don't want to introduce new code that has to be maintained with its own complexities. It is not going super fast, I know, but the project maintainer has been making progress on this new release and has been receptive to changes in the past, so I'd hold out a little bit longer. We will need those trim and indent features so if they don't get added in his new release, you could help expedite things by adding a PR to add them back here (or if it turns out too inefficient or cumbersome to do them post-parsing/post-stringifying, then maybe to propose a generic hook for comment-parser so we can supply a callback to do the trimming, etc.).

renatho

comment created time in 13 hours

issue commentgajus/eslint-plugin-jsdoc

Have namepath checks in `valid-types` only allow strict namepaths

Also, we should lint that certain kinds of child members have valid relationships to the parent in the namepath; for example (I'm not 100% sure about these because the JSDoc spec is poor):

* It is only valid for an event to have an instance membership (`#`).
  
  * Valid: `@event FooClass#event:EventName` or `@event FooClass#EventName`
  * Invalid: `@event FooClass~event:EventName` or `@event FooClass~EventName`

I think it should be possible that an event is defined as an inner object yet such an event instance is fired by a public method on that class and thus needs to document it is arising from a private.

class EventName {}

class FooClass {
  triggerEventName () {
    return new EventName();
  }
}

// ...

class PublicAPI {
  /**
   * @event FooClass~EventName
   */
  publicMethod () {
    return new FooClass().triggerEventName();
  }
}
  As a side note, it would also be nice to autofix event names to either have or not have the `event:` prefix for consistency. It's my preference to use the prefix everywhere instead of remembering it can be omitted in the `@event` and `@fires` tags.

Feel free to file a separate issue for this. We couldn't really determine if the event prefix was missing, e.g., on a @param unless on a tag like event, fires, listens (since we wouldn't know whether it was an event or something else).

* A typedef can only have an inner membership (`~`).
  
  * Valid: `@typedef {Object} FooClass~FooType`
  * Invalid: `@typedef {Object} FooClass#FooType`

I guess the idea here is that a public item would not just be abstract, and so a @typedef would not be suitable in such a case, right? (i.e., one would have to use a @namespace instead to define such a visible object.) Yes, I see the docs do at least suggest this if not recommend this.

Such a change sounds reasonable and would fit well with the change I think will be needed for this issue–to supply startRule: 'NamepathExpr' to our jsdoctypeparser call (we'd have to introspect on the owner of the parsed result to determine whether it is "MEMBER", "INNER_MEMBER", or "INSTANCE_MEMBER").

However, I think it should probably be added as a default-on option since the docs are not adamant that instance members cannot be used.

I spent a lot of time in jsdoc-md coming up with an elegant regex to reliably deconstruct and validate JSDoc namepaths, maybe you will find it useful:

* Source: https://github.com/jaydenseric/jsdoc-md/blob/v8.0.0/private/deconstructJsdocNamepath.js

* Tests: https://github.com/jaydenseric/jsdoc-md/blob/v8.0.0/test/private/deconstructJsdocNamepath.test.js

If you do want to use it, let me know and I will publish a package for it. It's my preference to share a proper dependency than have you cut and paste the code in with the MIT license mandated credit in a comment or something.

Thank you for the offer, but I really think this should be handled in jsdoctypeparser. The grammar makes it easy to understand and maintain (and ensure parsing improvements benefit other parsing uses within our project(s))--might even be useful for your project.

Btw, if anyone wants to help with a real bottleneck on jsdoctypeparser that is stalling some things on this project, we haven't been able to get semantic-release working, so any suggestions or help would be appreciated: https://github.com/jsdoctypeparser/jsdoctypeparser/pull/122 . With such a fix in place, we'd be in a better position to make releases there which can be more quickly surfaced in eslint-plugin-jsdoc.

I do have to mention that my health/energy has not been great though, so I'm having to slow down and am not necessarily going to be able to be reliable.

brettz9

comment created time in 13 hours

startedloreanvictor/callbag-common

started time in a day

startedssbc/ssb-private1

started time in a day

startedNUS-VIP/salicon-api

started time in a day

issue commentgajus/eslint-plugin-jsdoc

Have namepath checks in `valid-types` only allow strict namepaths

Also, we should lint that certain kinds of child members have valid relationships to the parent in the namepath; for example (I'm not 100% sure about these because the JSDoc spec is poor):

  • It is only valid for an event to have an instance membership (#).

    • Valid: @event FooClass#event:EventName or @event FooClass#EventName
    • Invalid: @event FooClass~event:EventName or @event FooClass~EventName

    As a side note, it would also be nice to autofix event names to either have or not have the event: prefix for consistency. It's my preference to use the prefix everywhere instead of remembering it can be omitted in the @event and @fires tags.

  • A typedef can only have an inner membership (~).

    • Valid: @typedef {Object} FooClass~FooType
    • Invalid: @typedef {Object} FooClass#FooType

I spent a lot of time in jsdoc-md coming up with an elegant regex to reliably deconstruct and validate JSDoc namepaths, maybe you will find it useful:

  • Source: https://github.com/jaydenseric/jsdoc-md/blob/v8.0.0/private/deconstructJsdocNamepath.js
  • Tests: https://github.com/jaydenseric/jsdoc-md/blob/v8.0.0/test/private/deconstructJsdocNamepath.test.js

If you do want to use it, let me know and I will publish a package for it. It's my preference to share a proper dependency than have you cut and paste the code in with the MIT license mandated credit in a comment or something.

brettz9

comment created time in a day

startedTribler/py-ipv8

started time in 2 days

pull request commentgajus/eslint-plugin-jsdoc

Fix check line alignment

@brettz9, I wonder if we could merge this fix for now, and when the comment-parser changes are done, we update this rule to use it.

Considering that probably it can take a while, I think it'd be nice to already fix this issue here. WDYT?

renatho

comment created time in 2 days

startedtrebleshot/android

started time in 2 days

issue commentgajus/eslint-plugin-jsdoc

Place auto-generated JSDoc comments above decorators/annotations

I am still seeing issues with this in the case of multiple annotations.
Version 30.7.8

It considers this valid:

@Injectable({
  providedIn: 'root',
})
@State<Partial<UserSettingsStateModel>>
({
  name: 'userSettings',
  defaults: {
    isDev: !environment.production,
  },
})
/** Defines the current user's settings. */
export class UserSettingsState { }

When run with --fix and no documentation, it attempts to place the doc comment line so:

@Injectable({
  providedIn: 'root',
})
@State<Partial<UserSettingsStateModel>>
/**
 *
 */
({
  name: 'userSettings',
  defaults: {
    isDev: !environment.production,
  },
})
export class UserSettingsState { }

It considers this "missing" (though VS Code picks it up fine)

/** Defines the current user's settings. */
@Injectable({
  providedIn: 'root',
})
@State<Partial<UserSettingsStateModel>>
({
  name: 'userSettings',
  defaults: {
    isDev: !environment.production,
  },
})
export class UserSettingsState { }
seanblonien

comment created time in 3 days

issue closedtc39/proposal-optional-chaining

Typo (missing the dot operator)

https://github.com/tc39/proposal-optional-chaining/blob/8461024a040d9c41ec039e2d4291fe2dfda36574/README.md#L58

The following constructs are missing the dot . operator: a?[b] or a?(b)

It should be: a?.[b] or a?.(b)

closed time in 3 days

RinatValiullov

issue commenttc39/proposal-optional-chaining

Typo (missing the dot operator)

No, because this sentence refers to the languages mentioned in the “Prior Art” section, not to ECMAScript.

RinatValiullov

comment created time in 3 days

issue openedtc39/proposal-optional-chaining

Typo (missing the dot operator)

https://github.com/tc39/proposal-optional-chaining/blob/8461024a040d9c41ec039e2d4291fe2dfda36574/README.md#L58

The following constructs are missing the dot . operator: a?[b] or a?(b)

It should be: a?.[b] or a?.(b)

created time in 3 days

startedstaltz/ssb-db-mock-feed-stream

started time in 4 days

created repositorystaltz/ssb-db-mock-feed-stream

Mock ssb.createFeedStream if you dont need it

created time in 4 days

pull request commentpostcss/postcss-calc

update: use PostCSS 8 API.

@ludofischer Let's use Once

ludofischer

comment created time in 4 days

startedcvzoya/figrim

started time in 4 days

pull request commentpostcss/postcss-calc

update: use PostCSS 8 API.

I think this pull request should not be merged in this state, there's a chance of infinite loops apprearing. I've added a test that produces an infinite loop: adding a plugin that changes whitespace inside the calc() property. I guess the 'right' solution would be to skip writing the value if we detect the parsed value AST are equivalent? Or just use Once() :-)?

ludofischer

comment created time in 5 days

issue commentgajus/eslint-plugin-jsdoc

Nested ArrowFunctionExpression false negatives at v30.0.2

Thanks!

I wasn't aware of the contexts option. After fiddling around in AST Explorer, I figured out how to revert to the old behavior:

   "jsdoc/require-jsdoc": ["error", {
        "contexts": [
          "VariableDeclarator > ArrowFunctionExpression"
        ]
    }]

FYI The breaking change was in v30.0.2. I guess I was the lucky one that coded against incorrect behavior :).

raineorshine

comment created time in 5 days

issue commentnodejs/mentorship

Widen the sidebar in the onboarding document

Yes! Would you be interested in making a PR for this issue?

choilmto

comment created time in 5 days

issue commentnodejs/mentorship

Widen the sidebar in the onboarding document

Looks like this is related to https://github.com/nodejs/mentorship/tree/master/onboarding_docs

choilmto

comment created time in 5 days

issue closedgajus/eslint-plugin-jsdoc

Nested ArrowFunctionExpression false negatives after v30

After upgrading to v30, I am getting false negatives (linter was passing before) on nested ArrowFunctionExpressions.

e.g.

// FALSE NEGATIVE: previously bar did NOT require a JSDOC with my configuration
const foo = {
  bar: () => {
    ...
  }
}

// an arrow function assigned to a `const` correctly requires a JSDOC
const moo: () => {
  ...
}

Here is my rule configuration:

    "jsdoc/require-jsdoc": [
      2,
      {
        "require": {
          "ArrowFunctionExpression": true,
          "ClassDeclaration": true,
          "ClassExpression": true
        }
      }
    ]

I've read the changelog for v30 but I am not able to connect the description of breaking changes to the above issue. Neither removing ArrowFunctionExpression nor setting publicOnly fixes it. Thanks for your help!

~My typescript version is ahead of the eslint parser, but it works fine on eslint-plugin-jsdoc v29.~

    "eslint": "^7.14.0",
    "typescript": "4.0.5",
    "@typescript-eslint/eslint-plugin": "^3.10.1",
    "@typescript-eslint/parser": "^3.10.1",

closed time in 5 days

raineorshine

issue commentgajus/eslint-plugin-jsdoc

Nested ArrowFunctionExpression false negatives after v30

I don't recall the history of the change--I think someone might have wanted ArrowFunctionExpression to be triggered regardless of context (as may technically be more consistent with the other types). But you can specify the context of interest by such as the following:

{
      contexts: [
        ':not(Property) > ArrowFunctionExpression',
      ],
      require: {
        ArrowFunctionExpression: false, // Disable to allow the more limited `contexts` to be applied
        ClassDeclaration: true,
        ClassExpression: true,
      },
    }

Closing as that should I think address it, but feel free to comment further.

raineorshine

comment created time in 5 days

issue openedgajus/eslint-plugin-jsdoc

Nested ArrowFunctionExpression false negatives after v30

After upgrading to v30, I am getting false negatives (linter was passing before) on nested ArrowFunctionExpressions.

e.g.

// FALSE NEGATIVE: previously bar did NOT require a JSDOC with my configuration
const foo = {
  bar: () => {
    ...
  }
}

// an arrow function assigned to a `const` correctly requires a JSDOC
const moo: () => {
  ...
}

Here is my rule configuration:

    "jsdoc/require-jsdoc": [
      2,
      {
        "require": {
          "ArrowFunctionExpression": true,
          "ClassDeclaration": true,
          "ClassExpression": true
        }
      }
    ]

I've read the changelog for v30 but I am not able to connect the description of breaking changes to the above issue. Neither removing ArrowFunctionExpression nor setting publicOnly fixes it. Thanks for your help!

created time in 7 days

startedvacancy/NSCL-PyTorch-Release

started time in 8 days

push eventnodejs/mentorship

github-actions[bot]

commit sha f0f34289394590320743216e7ac1db783241da6d

Deploy to GitHub pages

view details

push time in 9 days

push eventnodejs/mentorship

ah-superstruct

commit sha 1f7bc621caeb02cb132b039854fd19a66b0b2a53

add previousOpenings.md rm challenge and add mentorship initiative position record

view details

push time in 9 days

PR merged nodejs/mentorship

feat: add previousOpenings.md

Creates previousOpenings.md to serve as a reference of previous mentee openings. This includes the date the opening was closed with a link to the opening's blog post.

+8 -0

0 comment

1 changed file

LonelyTree

pr closed time in 9 days

more