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

WIP Fix js exports issues #1099

Merged
merged 4 commits into from
Aug 8, 2019
Merged

WIP Fix js exports issues #1099

merged 4 commits into from
Aug 8, 2019

Conversation

mstoykov
Copy link
Contributor

@mstoykov mstoykov commented Aug 2, 2019

No description provided.

@mstoykov mstoykov requested a review from na-- August 2, 2019 08:33
@codecov-io
Copy link

codecov-io commented Aug 2, 2019

Codecov Report

Merging #1099 into master will decrease coverage by 0.03%.
The diff coverage is 81.81%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1099      +/-   ##
==========================================
- Coverage   73.26%   73.22%   -0.04%     
==========================================
  Files         141      141              
  Lines       10251    10248       -3     
==========================================
- Hits         7510     7504       -6     
- Misses       2300     2302       +2     
- Partials      441      442       +1
Impacted Files Coverage Δ
js/initcontext.go 89.88% <81.81%> (-3.6%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8e93258...ebc684c. Read the comment docs.

@mstoykov
Copy link
Contributor Author

mstoykov commented Aug 5, 2019

After way more testing and banging of my head against a figurative wall, I managed to find out why the second fix works :) :

As is seen in that commit exports and module are being set to the goja.Runtime which basically sets them at the global scope. This was done before each import/require in order for subsequent exports/modules to not overwrite previous once. But after that the old ones are set back through the defers.

So that means that while during the execution of a module it sees it's exports/modules it sees the ones of the module that is entrypoint for the main function call. Usually(always in real k6 execution) this means the one of the main module - the one with the default function. Which is exactly what happens in the test - the function call to B during the execution of the main default function sees the exports/modules for the main script which are set at a different place.

When I changed it to instead have arguments to the function wrapper and provide the exports/module this way, they shadow the global ones and everything works as expected.

I suspect that the other fix works in some similar manner but also works around the fact that the main module's exports/module are still being set globally which I am going to test and change to work in the same way the import's ones work now.

@mstoykov mstoykov force-pushed the fixJSExportsIssues branch from c1477b2 to ebc684c Compare August 7, 2019 06:42
js/initcontext.go Show resolved Hide resolved
Copy link
Member

@na-- na-- left a comment

Choose a reason for hiding this comment

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

I've mostly grokked the changes here and don't see any issues so far...

@mstoykov mstoykov merged commit bd6d2d9 into master Aug 8, 2019
@mstoykov mstoykov deleted the fixJSExportsIssues branch August 8, 2019 08:16
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.

3 participants