-
-
Notifications
You must be signed in to change notification settings - Fork 123
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
feat: usage of ESLint v8 #274
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be worth adding a new test to ensure we allow top level-await, as we do for standard
:
https://github.com/standard/standard/blob/8d832307d9f4e5875c7c32487e596d29db2cf10f/test/validate-config.js#L11-L16
Except that, this looks good to me! 👍
Is there is anything missing, as this is still a draft?
@divlo I wanted to look into eg. the external tests + I was considering whether to wait for the |
Any update on this? Can we get this merged? |
Since I am not the only one who wants to use this updated version, I have published an npmjs version: https://www.npmjs.com/package/@umpacken/semistandard If you want to do a seamless update, you can use an npm alias in your package.json like this:
|
Hello my fine folks! I just pulled this branch and ran the tests as well as ran it against a project of mine which uses class private fields (the feature I want) and all seems to work well. I am happy to do what it takes to get help get this across the finish line if someone will but help me know what to do. A lot has changed, but I used to help maintain |
Hey @divlo, I noticed Pelle remove themselves so I am thinking maybe you are the right person to help. If this project is having resourcing troubles I am happy to help. If nothing else, we could just automate pulling in the latest |
Hey! @wesleytodd I think the PR is ready to land as is. There is a similar issue of long standing PR (even merged) but not released in The |
@divlo I sadly can't remember and sadly have no time to spend on Standard. I do agree that there are not enough active maintainers here. |
I tested it out and it worked without issue. Are there other checks you would usually do before releasing? I am happy to do them.
Who has publish on these? I wonder if we could add Release Please and then have whoever has the publish can add the tokens to the repos. Who is it that has publish rights on these two packages? I can't promise much time, but I have been a big fan of this approach to linting for a long time and really appreciate the work y'all have done to keep it going. If the project is suffering I can both keep an eye out for folks looking to contribute and point them here as well as give a little time/effort to helping automate parts like the merge and release flow so it is less hard to maintain the "forks" of |
@wesleytodd We can definitely automate the release process. There is a similar issue open in I'm not familiar with Release Please, but I think semantic-release can be a good fit too, similarly to mightyiam/eslint-config-love#840. Would be greatly appreciated if any one want to open a PR to setup the GitHub Actions to automate that. 👍 Meanwhile, we will merge this PR, it is ready. 🚀 |
My main reason for recommending release please is I trust it's author (Benjamin Coe, node.js core contributor and prolific module author) and it is well supported. For a while I was working with Ben and a few others on stuff related to conventional commits and it was while he was working on Release Please. I am happy to go whichever route folks already working in this project want, just sharing why I like Release Please :)
Yep, that is exactly why I think this kind of automation would be good. The publish token is still restricted, but "publish rights" are given to anyone with write access on the repo. |
A bit of "how the sausage is made" on these:
Not really a good reason to make a decision, but we were working on a v2 for Conventional Commits with the intent to better support monorepos and all the other stuff the original didn't really take into account. If folks ever have time to pick that work back up I think it will likely be where new supported features land first. |
@wesleytodd Sorry, maybe @feross, @LinusU, @Flet or someone else knows |
Thanks! I didn't want to bother you further, just wasn't sure who to ping who had publish rights. |
Since I did another release in the standard org I threw this in as well, |
Work in progress on upgrading this module to use the new
[email protected]
See standard/eslint-config-standard#229
Fixes #273