-
Notifications
You must be signed in to change notification settings - Fork 129
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: ES Module #419
feat: ES Module #419
Conversation
…ait `await import()` statements
@travi we get the error with |
yep, thats this issue. should be solved once that is merged. maybe we comment out the check for now while we wait on a new version? |
test/fail.test.js
Outdated
'./get-client': proxyquire('../lib/get-client', {'./definitions/rate-limit': rateLimit}), | ||
}); | ||
// mock rate limit imported via lib/get-client.js | ||
await quibble.esm('../lib/definitions/rate-limit.js', RATE_LIMIT_MOCK) |
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.
would it be better for this to be inside the beforeEach
?
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.
I don't think it's necessary, tests are passing just fine, but if you prefer I can move it into a a test.before(() => {...})
block?
Co-authored-by: Gregor Martynus <39992+gr2m@users.noreply.github.com>
…tch requests yet
@travi sorry it's quite the massive PR in the end, but I think this is ready
|
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.
i havent gotten very deep yet, but have a couple of thoughts for tonight. i'll continue to review again later
context | ||
); | ||
const { owner, repo } = parseGithubUrl(repositoryUrl); | ||
const octokit = new Octokit( |
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.
to build on the injection question above, i'm curious if there would be value in passing an instance through rather than passing the constructor and constructing here and various other places.
two potential benefits:
- would there be runtime benefits to using fewer instances throughout? it looks like the previous get-client approach still constructed a new instance each time, so this approach is pretty similar in this regard.
- would there be value in reducing the places where the instantiation logic exists by injecting an instance?
these are just questions for consideration. i'm good with either approach
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.
I had the same thought but didn't want to overburden this pull request. It would be an internal refactoring so shouldn't impact future releases.
Main benefit of having a shared octokit
instance is that it would share the same throttling state. But it would be a side effect, which we already do for the verified
flag here: Line 12 in /index.js
We could add a singleton octokit
instance. That is initiated first time any of the plugin methods are called? Only problem I see is that it would break if the different methods would be called with different configuration, but that doesn't seem to be a problem?
Do you have an idea how we might avoid the side effect for both octokit
and verified
? It's bound to cause trouble eventually, it aways does 🤣
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.
I had the same thought but didn't want to overburden this pull request. It would be an internal refactoring so shouldn't impact future releases.
i think this is where my head is too. even if we do think it is a worthwhile change, it feels worthwhile to defer until after merging the rest of this change and releasing to latest.
would it be worth capturing an issue for later (optional) consideration? that way we are less likely to lose track of the thoughts you've shared here if we do decide to revisit?
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.
The only way I can think of is for semantic-release plugins to have a function that needs to be called, which then in turn returns the lifecycle functions. I guess we could add that functionality to semantic-release
and support both patterns for a while or even forever. But for the time being we do the side effect?
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.
would it be worth capturing an issue for later (optional) consideration
yes I'll do that. I'll probably send a pull request right away so we can discuss it in isolation, and then do a follow up issue to discuss the new plugin API which would export a single function as default export that works as a factory function for the lifecycle APIs to contain state / avoid side effects
not sure what your plan is for merging this into beta, but if we don't squash, i think it could be a good idea to capture the prettier commit(s) to be ignored from blame, like we did in https://github.com/semantic-release/semantic-release/blob/master/.git-blame-ignore-revs and others. also, since beta is behind master, we could avoid some conflicts when merging beta to master if we dont squash. alternatively, maybe it is worth getting beta up to date with master before we merge this into beta? |
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.
i've looked through all of the source files so far, but need to step away again for now. i don't expect any big concerns with the test files, though, so this is looking great!
main thing so far is just the simplification of the dependency injection for the octokit constructor in the various places where defaults arent needed
@@ -68,8 +67,8 @@ | |||
"version" | |||
], | |||
"license": "MIT", | |||
"main": "index.js", | |||
"nyc": { | |||
"exports": "./index.js", |
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.
glad you handled this detail. i've noticed that we missed it on some of our other conversions. we'll have to remember to cover those when we make our next breaking changes for them
context | ||
); | ||
const { owner, repo } = parseGithubUrl(repositoryUrl); | ||
const octokit = new Octokit( |
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.
I had the same thought but didn't want to overburden this pull request. It would be an internal refactoring so shouldn't impact future releases.
i think this is where my head is too. even if we do think it is a worthwhile change, it feels worthwhile to defer until after merging the rest of this change and releasing to latest.
would it be worth capturing an issue for later (optional) consideration? that way we are less likely to lose track of the thoughts you've shared here if we do decide to revisit?
I recently re-created beta on top of master and resolved all conflicts. I can re-create beta on top of latest master before merge again. How about I squash all commits except the prettier changes before merging into |
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.
the remainder looks good to me. a lot of formatting changes to sort through, so let me know if there is anything in particular you'd like to make sure i got my eyes on beyond the dependency injection pieces
that sounds good to me 👍🏼 |
🎉 This PR is included in version 9.0.0-beta.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
🎉 This PR is included in version 9.0.0-beta.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
fixes #418
closes #330, closes #358, closes #390, closes #395, closes #396, closes #515, close #548, closes #580, closes #627, closes #628, closes #630, closes #631, closes #635
For reference, because it came up in other discussions, here is how I replaced
proxyquire
withquibble
BREAKING CHANGE:
@semantic-release/github
is now a native ES Module. It has named exports for each plugin hook (verifyConditions
,publish
,addChannel
,success
,fail
)BREAKING CHANGE: in case of error, the thrown error is not iterable directly. Use the
error.errors
property instead (viaaggregate-error
v4.0.0)Todos
xo
, just use prettier without any config (feat: ES Module #419 (comment))testdouble
(feat: ES Module #419 (comment))Reminder to self: run a single test: