Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require a GitHub issue for TODOs #30

Closed
pixelzoom opened this issue Jan 15, 2023 · 5 comments
Closed

Require a GitHub issue for TODOs #30

pixelzoom opened this issue Jan 15, 2023 · 5 comments

Comments

@pixelzoom
Copy link
Contributor

In Slack#pistachio on 1/12/23, @zepumph said:

Since there are so many people working for number-play and associated repos, I would like to add the lint rule where we require issues for todos. There are only 5 failures currently. Do we like that idea to help keep things organized?

There were definitely more than 5 TODOs for "for number-play and associated repos" that do not have an associated GitHub issue. And I don't see details in that Slack thread about what @zepumph actually did.

What I do see is that grunt lint is not identifying all TODOs that are missing associated GitHub issues, for example lots that were identified in #28. And I don't see any specific lint rules being added in package.json files for the number suite.

So a request for @zepumph... Could you please:
(1) Describe what you did
(2) Fix things so that we cannot inadvenrtently added more TODOs without a GitHub issue

@zepumph
Copy link
Member

zepumph commented Jan 16, 2023

  1. This particular custom lint rule doesn't behave like standard rules, so my change was phetsims/chipper@5840322.
  2. I don't know what was happening, and I can't reproduce this error, though I definitely could back when I originally committed the above commit, since I didn't get all TODOs. I'm not really sure how to solve the lint rule since you already fixed things. When I remove one issue link, lets say for something like this commit line, it immediately marks it as failing.

My best guess for this failure is lint caching; this is because opting in to a new repo for this rule involves changing the rule itself, which is heavily cached, and could result in different behavior on different machines depending on how that cache is broken.

I first want to update to rule to get away from that paradigm. I know why it was originally done like that, because we only put that rule into anything in phetLibs that isn't scenery,kit,dot, and perennial-alias. Now though, I feel like it would be better to make it opt out, depending on how much effort it would be to make that happen. I'll take a look. We can always make it opt in.

@zepumph
Copy link
Member

zepumph commented Jan 16, 2023

Over in phetsims/chipper#1372 (comment), I updated the lint rule so that it behaves as expected better.

I also realized that in phetsims/chipper@5840322, I didn't add counting-common. We should do that!

@pixelzoom
Copy link
Contributor Author

Looks good. Back to @zepumph in case there's anything else to do. Feel free to close.

@pixelzoom pixelzoom assigned zepumph and unassigned pixelzoom Jan 17, 2023
@chrisklus chrisklus assigned chrisklus and unassigned zepumph Jan 18, 2023
@chrisklus
Copy link
Contributor

I also realized that in phetsims/chipper@5840322, I didn't add counting-common. We should do that!

I added counting-common to todo-should-have-issue over in phetsims/counting-common#11. All four repos now have this lint rule and are passing.

Passing back to @zepumph for final review in case there's any work left from #30 (comment).

@chrisklus chrisklus assigned zepumph and unassigned chrisklus Jan 19, 2023
@zepumph
Copy link
Member

zepumph commented Jan 19, 2023

Amazing and I love phetsims/counting-common@9f170ec. Closing

@zepumph zepumph closed this as completed Jan 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants