by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 21 23:53
    ethancrook99 synchronize #766
  • Sep 21 15:48
    ethancrook99 commented #766
  • Sep 21 15:47
    ethancrook99 synchronize #766
  • Sep 21 15:18
    lgrammel opened #770
  • Sep 21 14:30
    ethancrook99 commented #766
  • Sep 20 18:36
    benjamn commented #766
  • Sep 20 18:35
    benjamn commented #766
  • Sep 19 19:29
    mjfaga commented #766
  • Sep 19 19:29
    mjfaga opened #769
  • Sep 18 05:50

    dependabot[bot] on npm_and_yarn

    (compare)

  • Sep 18 05:50
    dependabot[bot] closed #760
  • Sep 18 05:50
    dependabot[bot] commented #760
  • Sep 18 05:50
    dependabot[bot] labeled #768
  • Sep 18 05:50
    dependabot[bot] opened #768
  • Sep 18 05:50

    dependabot[bot] on npm_and_yarn

    Bump flow-parser from 0.132.0 t… (compare)

  • Sep 18 05:50

    dependabot[bot] on npm_and_yarn

    (compare)

  • Sep 18 05:50
    dependabot[bot] closed #765
  • Sep 18 05:50
    dependabot[bot] commented #765
  • Sep 18 05:50
    dependabot[bot] labeled #767
  • Sep 18 05:50

    dependabot[bot] on npm_and_yarn

    Bump @types/node from 14.10.0 t… (compare)

Jeroen Engels
@jfmengels
Hey guys, I'm trying to write a codemod, and one of the things I want it to do is to remove console.log()s. As you can see here https://astexplorer.net/#/qIaPrYrZsE, it messes up my comments, and I can't figure out how to fix it. (It's written jusing jscodeshift, but I'm trying alternatively to do it with recast, but not with a lot of success either). Thanks!
Ben Newman
@benjamn
@jfmengels when using Recast, you should ignore .leadingComments and .trailingComments
all comments are attached to nodes in a .comments array, and each comment has two boolean properties, .leading and .trailing
I suspect in this case that the console.log ExpressionStatement has a .comments array with one trailing comment
when you remove the console.log statement, you should probably concatenate its .comments property with any .comments on the previous node (the _.set statement, this case)
Jeroen Engels
@jfmengels
Yes, I've been trying that, can't seem to get it right. Either they disappear, or they appear as leading comments, though they should be trailing.
(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!