ES6 migration, repo harminization by pvdlg · Pull Request #451 · semantic-release/semantic-release

pvdlg · 2017-09-29T20:50:37Z

ES 6 + AVA + test refactoring:
- Use async/await instead of callbacks
- Use execa to run command lines
- Use AVA for tests
- Add several assertions in existing unit tests
- Add documentation (comments) in the tests
- Run tests with a real git repo instead of mocking child_process and add test helpers to create repos, commits and checkout
- Simplify test directory structure
- Simplify code readability (mostly with async/await)
- Switch from standard to eslint + eslint-config-standard + prettier
Add a License file + badge
Remove npm and yarn lockfile
Use a more generic .gitignore that would work on Windows, Linux, Mac OS
Add badges

The test coverage appear to be worse than before because src/index.js was not included in the coverage and it is now. The coverage is actually a bit better now.
I'll add more tests in a following PR.

Overall this PR doesn't change functionality, and does not fix bugs. It makes code and unit/integration tests more readable and easier to understand, hopefully making the project more accessible to contributors.

I found several improvement and bugs to fix will rewriting the tests. That will come in following PRs.

Fix #391, Fix #378, Fix #361

gr2m · 2017-09-29T22:37:21Z

+      '-E',
+      '--format=%H==SPLIT==%B==END==',
+      `${lastRelease.gitHead ? lastRelease.gitHead + '..' : ''}HEAD`,
+    ]));


do we need to wrap this block into ()?

I’ve seen it in a few other places, too

Yes in order to reuse the stdout variable.
See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#Assignment_without_declaration

I could also use different variables.

ah got it, it’s fine, code is readable as is, I was just curious. And learned something, thanks 👍

I'm thinking of doing a bit more refactoring in other PR actually. Mostly modularize a bit and splitting thing in different function.
That would make the code clearer, allow us to write more docs in the form of jsdoc.
Also that would simplify a lot the situation like were have to reuse variable.

Most of the case I do that is due to try / catch to avoid having all the code depending the throwing function be part of the try block.

With more modularization, each function that throws could handle it's errors (ie process the error and rethrow a SemanticRealseError) so in the parent module that calls them we could have only one try catch block.

I'm thinking of doing a bit more refactoring in other PR actually. Mostly modularize a bit and splitting thing in different function.
That would make the code clearer, allow us to write more docs in the form of jsdoc.
Also that would simplify a lot the situation like were have to reuse variable.

yeah +1 on doing that in follow up PRs, this one is quite big already

With more modularization, each function that throws could handle it's errors (ie process the error and rethrow a SemanticRealseError) so in the parent module that calls them we could have only one try catch block.

Sounds good to me

luftywiranda13 · 2017-09-29T22:43:46Z

+
+package-lock.json
+yarn.lock
+


EDITED: ignoring lockfiles like this is harmful, because lockfiles are still in your local machine (they're just invisible)
See https://github.com/luftywiranda13/remove-lockfiles#why

What do you mean 'they're just invisible' ?
If they are not committed to the repo, they are not in the repo.

Also I added npmrc and .yarnrc to not regenerate them.

i updated my comment, sorry 😆

Also I added npmrc and .yarnrc to not regenerate them.

2 dotfiles to prevent lockfiles to be generated? I think it's overkill

The point of removing the lockfiles is to do the development with latest versions of dependencies. Your solution (unless I'm missing something) just remove the lockfiles before commit even though they wouldn't be committed anyway due to gitignore.

That doesn't solve the problem as the lockfile will be present on the local machine until the contributor do a commit. So a contributor would do all the development and run the test locally with potentially outdated libraries. Therefore what worked on their local machines might not work on the CI.

Also adding 2 extra dependency + a commit hook seem more overkill to me than two one line dotfiles.

The point of removing the lockfiles is to do the development with latest versions of dependencies.

yes, I know. that's the main reason why I decide to never commit lockfiles in my projects

Also adding 2 extra dependency + a commit hook seem more overkill to me than two one line dotfiles.

hmmm I think #451 (comment) is a relevant answer

luftywiranda13 · 2017-09-29T22:58:49Z

-    "nyc": "^10.0.0",
+    "nyc": "^11.2.1",
+    "p-map-series": "^1.0.0",
+    "prettier": "^1.7.0",


Isn't it better to integrate prettier + eslint in pre-commit hook?
So we can make sure prettier + eslint reformat any changes before committing

Also this approach will reduce the possibility of us having code style discussion in code review
#451 (comment)

Edited: if i got it right ✌️

We had this discussion about commit hook previously among maintainer and we've decided to not use commit hook for simplicity. Also that could create confusion for contributors to see their code automatically changed on commit.

The chosen solution is to enforce the formating with eslint (with eslint-plugin-prettier).
All the code format pushed is validated in CI with eslint to be sure it's formatted with prettier.

This comment is not really about style but more about a not well know javascript feature allowing to reassign let variables with destructuring.

We had this discussion about commit hook previously among maintainer...

cool, I respect that 👍

The chosen solution is to enforce the formating with eslint (with eslint-plugin-prettier).
All the code format pushed is validated in CI with eslint to be sure it's formatted with prettier.

yeah, the changes will fail on CI if they're not following our prettier config but then we still have to discuss about the code style things in the PR, right? isn't it not so good in terms of productivity?

Not really because eslint will run on npm run test. So a contributor would figure that out before committing.
Sure we could run npm run test on each commit or something like that but:

Most contributor would know they have to at least run unit test before commiting

For some less experienced contributors, we prefer answer them in the PR and help them as we believe guidance from a human would be more pleasant and helpful than an error message on commit

And there wouldn't be any style discussion, the style is enforced by eslint + prettier. There would be just explanation on how to read the eslint error, how to format properly, and maybe suggestion to use tools etc...Anything helpful for the contributor.

they will also fail when you run npm test locally

luftywiranda13 · 2017-09-29T23:00:17Z

+    "singleQuote": true,
+    "bracketSpacing": false,
+    "trailingComma": "es5"
+  },


IMO it's better to put prettier config directly inside eslint config. we're using eslint-plugin-prettier, right?

No because prettier config is read by editor tools and by the prettier command itself.
Actually it work the other way around, it's eslint-plugin-prettier that read the prettier config. See prettier/eslint-plugin-prettier#55

Actually it work the other way around, it's eslint-plugin-prettier that read the prettier config. See prettier/eslint-plugin-prettier#55

yeah, it's added in v2.3.0. but it still can read the config directly if we put the config in rules field

Prettier config in prettier property, Eslint config in eslintConfig property seems more clear to me. Not sure what would be the point of moving it around.
But thanks for the feedback :)

gr2m · 2017-09-29T23:15:54Z

do you know what’s up with codecov?

pvdlg · 2017-09-29T23:20:03Z

do you know what’s up with codecov?

Yes, it's because codecov has nothing to compare against to figure out if the coverage reduced as it has never ran on caribou branch.
All other PR after this one will work as expected.

But let me check if I can put a config to not report statuses when there is no comparison point.

gr2m

🚢

thanks for the review & comments @luftywiranda13

pvdlg · 2017-09-29T23:36:14Z

So there is a way to prevent codecov to fail on the first PR that use it: https://github.com/codecov/support/issues/173#issuecomment-216067683

But apparently it can also create situation in which Codecov would report success when coverage may be faulty.
As this would happen only on the first PR that configure Codecov, it's probably better to keep configured the way it is now.

gr2m · 2017-09-29T23:40:23Z

yeah feel free to merge it as is any time, I just don’t do it myself because I’m not sure if you still fine tuning it :)

pvdlg · 2017-09-29T23:45:01Z

I'm fine with it as is. I'm gonna wait a few hours while I work on the following PR locally in case anyone as additional comments.

@luftywiranda13 Thanks for the review 👍
If you have any more comments/review, feel free to add them :)

- Use async/await instead of callbacks - Use execa to run command line - Use AVA for tests - Add several assertions in the unit tests - Add documentation (comments) in the tests - Run tests with a real git repo instead of mocking child_process and add test helpers to create repos, commits and checkout - Simplify test directory structure - Simplify code readability (mostly with async/await) - Use eslint for for linting, prettier for formatting

- Avoid double build on PR - Add git fetch depth - Remove cache - Retry npm install

gr2m · 2017-09-30T19:07:02Z

🙌

pvdlg added 4 commits September 29, 2017 16:42

chore: Add license file

65c78d4

chore: Remove lockfiles

366501e

chore: More generic .gitignore (Windows, Mac OS, Linux)

e886bdd

chore: Remove editorconfig

58bf016

pvdlg requested a review from gr2m September 29, 2017 20:50

pvdlg force-pushed the es6-ava branch from b43b37c to 84b9f5d Compare September 29, 2017 20:53

gr2m reviewed Sep 29, 2017

View reviewed changes

luftywiranda13 reviewed Sep 29, 2017

View reviewed changes

gr2m approved these changes Sep 29, 2017

View reviewed changes

pvdlg force-pushed the es6-ava branch 3 times, most recently from fc06332 to d505b5b Compare September 30, 2017 05:17

pvdlg added 4 commits September 30, 2017 01:20

ci: Use codecov for code coverage

d0f5668

ci(travis): Update .travis.yml

8c0de21

- Avoid double build on PR - Add git fetch depth - Remove cache - Retry npm install

chore: Update badges

d505b5b

pvdlg merged commit a58d12d into caribou Sep 30, 2017

pvdlg deleted the es6-ava branch September 30, 2017 17:30

pvdlg mentioned this pull request Oct 6, 2017

Exit with 1 if unexpected error happens #462

Merged

LadyK-21 mentioned this pull request Jun 22, 2022

[Snyk] Upgrade @semantic-release/npm from 7.0.10 to 9.0.1 LadyK-21/semantic-release#5

Open

golfviva mentioned this pull request Jul 10, 2023

[Snyk] Security upgrade @semantic-release/release-notes-generator from 6.1.1 to 11.0.3 golfviva/semantic-release#16

Open

Bhanditz mentioned this pull request Jul 10, 2023

[Snyk] Security upgrade @semantic-release/release-notes-generator from 7.3.5 to 11.0.3 Bhanditz/semantic-release#22

Open


		package-lock.json
		yarn.lock

Uh oh!

Conversation

pvdlg commented Sep 29, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

luftywiranda13 Sep 29, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

luftywiranda13 Sep 29, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

luftywiranda13 Sep 29, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gr2m commented Sep 29, 2017

Uh oh!

pvdlg commented Sep 29, 2017

Uh oh!

gr2m left a comment

Choose a reason for hiding this comment

Uh oh!

pvdlg commented Sep 29, 2017

Uh oh!

gr2m commented Sep 29, 2017

Uh oh!

pvdlg commented Sep 29, 2017

Uh oh!

gr2m commented Sep 30, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

pvdlg commented Sep 29, 2017 •

edited

Loading

luftywiranda13 Sep 29, 2017 •

edited

Loading

luftywiranda13 Sep 29, 2017 •

edited

Loading

luftywiranda13 Sep 29, 2017 •

edited

Loading