Esm: 3.0.35: some regression with local file mocking

Created on 20 May 2018  Â·  3Comments  Â·  Source: standard-things/esm

Hello again.

Tried to upgrade mocku to 3.0.35 – https://github.com/deepsweet/mocku/pull/1

2 tests "scoped file: unmock" and "not scoped file: mock" started to return correct results which were wrong before, I just somehow missed it and didn't report here.

But one test "scoped file: mock" now returns an empty {} object instead of a mock. Works fine with 3.0.34, you can try to run them with yarn start test or npx start test.

bug needs tests

Most helpful comment

2 tests "scoped file: unmock" and "not scoped file: mock" started to return correct results which were wrong before, I just somehow missed it and didn't report here.

Nice!

But one test "scoped file: mock" now returns an empty {} object instead of a mock. Works fine with 3.0.34, you can try to run them with yarn start test or npx start test.

Ah, I think I know the root cause. I had added an optimization to remove binding setters for things that normally only happen once (like returning the namespace object from a dynamic import). With mocking however that assumption is no longer true. I'll look into if I can find a balance between the two.

Update:

I've removed the problem optimization for now and will work on a unit test using mocku to ensure it continues to work _(for that at least)_.

Update:

In a future release I may add a mock option to better support scenarios like #266 and allow optimizations for the common case _(unmocked)_.

Update:

v3.0.37 is released :tada:

All 3 comments

Same thing occurs for 3.0.36

2 tests "scoped file: unmock" and "not scoped file: mock" started to return correct results which were wrong before, I just somehow missed it and didn't report here.

Nice!

But one test "scoped file: mock" now returns an empty {} object instead of a mock. Works fine with 3.0.34, you can try to run them with yarn start test or npx start test.

Ah, I think I know the root cause. I had added an optimization to remove binding setters for things that normally only happen once (like returning the namespace object from a dynamic import). With mocking however that assumption is no longer true. I'll look into if I can find a balance between the two.

Update:

I've removed the problem optimization for now and will work on a unit test using mocku to ensure it continues to work _(for that at least)_.

Update:

In a future release I may add a mock option to better support scenarios like #266 and allow optimizations for the common case _(unmocked)_.

Update:

v3.0.37 is released :tada:

Confirm it fixes the issue for me also.

Was this page helpful?
0 / 5 - 0 ratings