Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 29 16:14
    ethancrook99 commented #766
  • Sep 29 16:14
    ethancrook99 synchronize #766
  • Sep 29 06:10

    dependabot[bot] on npm_and_yarn

    (compare)

  • Sep 29 06:09
    dependabot[bot] closed #772
  • Sep 29 06:09
    dependabot[bot] commented #772
  • Sep 29 06:09
    dependabot[bot] labeled #774
  • Sep 29 06:09
    dependabot[bot] opened #774
  • Sep 29 06:09

    dependabot[bot] on npm_and_yarn

    Bump @typescript-eslint/parser … (compare)

  • Sep 28 20:09
    eventualbuddha commented #766
  • Sep 28 16:40
    ethancrook99 commented #766
  • Sep 28 06:43

    dependabot[bot] on npm_and_yarn

    (compare)

  • Sep 28 06:43
    dependabot[bot] closed #761
  • Sep 28 06:43
    dependabot[bot] commented #761
  • Sep 28 06:43
    dependabot[bot] labeled #773
  • Sep 28 06:43
    dependabot[bot] opened #773
  • Sep 28 06:43

    dependabot[bot] on npm_and_yarn

    Bump eslint from 7.8.1 to 7.10.… (compare)

  • Sep 25 14:54
    ethancrook99 commented #766
  • Sep 24 15:45
    eventualbuddha commented #766
  • Sep 24 15:21
    ethancrook99 review_requested #766
  • Sep 22 06:11

    dependabot[bot] on npm_and_yarn

    (compare)

Jeroen Engels
@jfmengels
(FYI In this example, there are two console.logs, both followed by comments. The first one (=> 4) has leading=true, the second (=> 5) has trailing=true for some reason)
Ben Newman
@benjamn
wouldn't disappearing be a reasonable behavior in this case? since you're removing the node that the comments were trailing?
Jeroen Engels
@jfmengels
Yes. I meant that even by reattaching them to the previous statement, they either disappear or appear not where I expect them to be
Ben Newman
@benjamn
turning trailing comments into leading comments is the only sane thing to do in some cases: benjamn/recast#191
(aside: asking yourself where you (as a human) would ideally put a comment after removing its node is a luxury that you have that no algorithm will ever have)
what happens if you don't try to do anything special with the comments? just remove the console.log statements?
Jeroen Engels
@jfmengels
Then the console.log get removed, and only the second comment disappears
Ben Newman
@benjamn
oh ok, looking at the explorer, it looks like the first comment gets classified as a leading comment for the second _.set statement
and the second comment is a trailing comment for the second console.log, as you would hope
Jeroen Engels
@jfmengels
Aaah... that makes sense (not why it would do that, but now I understand why it's leading)
Ben Newman
@benjamn
Jeroen Engels
@jfmengels
Ok, well I fixed my problem by simply removing the console.log() before parsing it through jscodeshift for other transformations. I feel stupid not having thought about that before. Thanks for the explanation, I think I understand why comments are such a distinct entity in the AST (since hey can pop up pretty much anywhere)
But, does that mean that, using a tool like jscodeshift to modify huge chunks of code, there is a lot of change of removing comments or rearraging them in an inappropriate order?
Ben Newman
@benjamn
my hope is that you mostly don't have to think about comments
for better or worse, if you replace a node that had comments, the comments tend to disappear, which isn't great
Jeroen Engels
@jfmengels
No, I'll try to remind myself to check the diff when I apply codemods to make sure none disappeared.
Ben Newman
@benjamn
when I've done big codemods with recast, I pay a lot of attention to what happens to the comments
sometimes I can tweak the comments handling code to fix the problem, but sometimes I have to tweak the hard cases manually and rerun the codemod
Jeroen Engels
@jfmengels
What happens most of the time? A lot of things going awry or is it pretty ok?
Ben Newman
@benjamn
mostly comments disappearing, sometimes trailing/dangling comments becoming leading
Jeroen Engels
@jfmengels
ok, so I should always check the diffs
Ben Newman
@benjamn
yeah :/
if the comment was a leading comment to begin with, it will usually survive just fine, so the tweaks I mentioned are usually finding ways to turn weird trailing comments into leading comments
Jeroen Engels
@jfmengels
I see
Jeroen Engels
@jfmengels
Btw, you might like the use I'm making of jscodeshift/recast: I'm working on generating the lodash/fp docs (a variant of lodash where all arguments are in a different order, among other things), and I'm using it in order to update the examples written in the JSDoc of the sources (so they need to be generated automatically)
Thought you'd like to know
Ben Newman
@benjamn
neat!
that does make sense
if you're only modifying the text of comments, they should get reprinted in-place, without any trouble
even so, figuring out which nodes the comments are attached to (and writing code that gets it right every time) can be tricky
please let me know how it goes :)
Jeroen Engels
@jfmengels
I'm not changing the text of comments (for now, hoping to not having to resort to custom cases if possible), but the console.log()s don't make much sense with lodash/fp in the examples, that's why I wanted them gone.
Sure, will do!
(and just filtering out the lines with console.logs does the trick, so we're good there)
Ben Newman
@benjamn
yeah, that's another thing: sometimes it's a lot easier to do a dumb preprocessing step than it is to figure out how to write a smart transform
Jeroen Engels
@jfmengels
Yes, lesson learned ;) (or so I hope)
Ben Newman
@benjamn
it's all about your productivity :)
Jeroen Engels
@jfmengels
Well, I spent a few evenings on this, where I kept thinking in the "jscodeshift box", not outside the box
Ok, off to bed. Thanks a lot @benjamn, and I'll let you know how it goes ;)
Ben Newman
@benjamn
good luck & take care!
Jeroen Engels
@jfmengels
Hey!
I'm off to bed, but just wanted to let you know that my (second) PR for the lodash docs has been merged lodash/lodash#1963.
Original core docs: https://github.com/lodash/lodash/blob/4.3.0/doc/README.md
Generated fp docs: https://gist.github.com/jfmengels/6b973b69c491375117dc#_pullatindexes-array (scroll a little bit down)
Have a good one ;)
Benjamin Tan
@demoneaux
Hi @benjamn I sent in a few PRs recently, wonder if you've seen them?
demetriusnunes
@demetriusnunes
hi guys, wonder if you could help me. I'm just starting with codemods, and I wonder how could use it to instrument my code, ie, add logging statements at the beginning of each function. has anyone done that?
Brendan Annable
@BrendanAnnable
Buzzing in here!
Any thoughts on adding jsdoc/closure compiler annotations support? Or adding some plugin architecture for externally adding support?
My goal is to use recast as a general programmatic refactoring tool, but I need it to refactor the typing information along with it.
There is a parser here https://github.com/hegemonic/catharsis but it does not appear to support codegen.
jsdoc also has an internal parser that you can't really access properly, but again no codegen either.
Ben Newman
@benjamn
@BrendanAnnable is there an AST specification for that parser? And, at a minimum, does it generate AST nodes that have .loc.{start,end} information?
Brendan Annable
@BrendanAnnable
@benjamn So that parser only parses the typing information, so I doubt it would have .loc information. i.e. if you have a comment e.g. /** @type {Array<SomeFancyType>} */ it won't actually parse the entire comment, just the Array<SomeFancyType> part.