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

Remove moment.js dependencies #368

Merged
merged 4 commits into from
Aug 16, 2017

Conversation

jakub-wojciechowski
Copy link
Contributor

Following the discussion with @frangio in PR #353

As testrpc uses plain time arithmetic for time manipulation, using moment.js which is based on the implementation of full calendar logic brings a potential risk of indeterministic errors in tests.

Copy link
Contributor

@frangio frangio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work!

There are a lot of changes in yarn.lock which are unrelated to removing moment.js. Can you look into that? Make sure to have your dependencies as specified after #363. Sorry for the confusion. As for keeping package-lock.json in sync, it suffices to remove the "moment" entry.

@@ -43,5 +43,7 @@ export const duration = {
minutes: function(val) { return val * this.seconds(60) },
hours: function(val) { return val * this.minutes(60) },
days: function(val) { return val * this.hours(24) },
weeks: function(val) { return val * this.days(7) }
weeks: function(val) { return val * this.days(7) },
months: function(val) { return val * this.days(30)},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking we should only provide time units matching those of Solidity. months is not included and I see you haven't used it anywhere either. What do you think about removing it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it makes a total sense to mimic the solidity constants. Thanks for pointing that out!

@@ -29,26 +28,26 @@ contract('TokenTimelock', function ([_, owner, beneficiary]) {
})

it('cannot be released just before time limit', async function () {
await increaseTime(moment.duration(0.99, 'year').asSeconds())
await increaseTimeTo(this.releaseTime - duration.seconds(3))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm surprised this works. Given the lack of precision of increaseTimeTo that we've discussed, I would've thought 3 seconds was not enough to make up for it. Did you try other values?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As testrpc is run on localhost the lag is usually up to 1s. Due to time rounding, subtracting a single second is not enough to have a robust behaviour but 3s seems to be safe enough.

Obviously, the situation may change if someone decides to run tests across testrpc instance connected. But, to be honest, I don't expect it to be a common practice.

@jakub-wojciechowski
Copy link
Contributor Author

@frangio I've included all of the latest changes and generated a new yarn.lock. I suppose the inconsistency is caused by us using different versions of yarn. Can you please tell me yours (mine is 0.24.5) so I can double check if that's the case before committing updates.

@frangio
Copy link
Contributor

frangio commented Aug 14, 2017

yarn version 0.28.4

You should remove your node_modules folder and run yarn install using the lockfile that is in the repo. Removing moment would then result in very small changes to yarn.lock.

@jakub-wojciechowski
Copy link
Contributor Author

Switching to version 0.28.4 helped.
I still needed to manually switch positions of two versions of the same dependency that were next to each other (I guess yarn is not 100% deterministic) but apart from moving one paragraph to the top of another, the rest was identical.

@frangio
Copy link
Contributor

frangio commented Aug 16, 2017

Excellent. Thanks @jakub-wojciechowski!

@frangio frangio merged commit 0ed98ea into OpenZeppelin:master Aug 16, 2017
ProphetDaniel pushed a commit to classicdelta/Smart-Contracts that referenced this pull request Mar 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants