sysgears/mochapack

Victor Vlasenko

@larixer

Hey there

Andrew Kaiser

@andykais

hi @vlasenko, Im continuing our discussion on sysgears/mochapack#11

so Ill try to make my question as concise as possible:
how can I run mochapack when my project has multiple entrypoints, one that is called by the test file (lets call it main, and another that is forked from the main file).

When building the project normally, this is what the folder structure looks like

src/
  main.js
  child.js
build/
  main.js
  child.js

so in ./build/main.js, we try to run fork('./child.js'), but when using mochapack, as far as I know, there arent physical files written anywhere, and the entrypoints are ignored, so there is no ./child.js file built

Victor Vlasenko

@larixer

@andykais What is built as far as I understand is determined by webpack, not by fork. You are forking to execute, not build

@andykais You have build/child.js file and it should be perfectly seen by mochapack, since it is on the file system

Andrew Kaiser

@andykais

I can get it to work, but the build folder only exists if I run webpack before mochapack

webpack
# now the ./build directory exists
mochapack --watch
# now we can test with the build folder, but it will not get rebuilt if there are changes

Victor Vlasenko

@larixer

Ah, yes... now, I think I understood

Yes, mochapack output built files to the memory

Andrew Kaiser

@andykais

yeah thats what I was afraid of :/ Im not sure how feasible a change to mochapack for this would be

Victor Vlasenko

@larixer

But these modules that mochapack outputs into memory, they should be accesible for require

Yeah, but they are requirable only in the main process, not for child processes...

Previously mocha-webpack pre 1.0 has generated files to filesystem, but that has been changed in version 1.0 and later

Andrew Kaiser

@andykais

yeah Im looking into it, but generally they cannot be forked, unless you do some weird eval magic. The use cases are pretty far reaching, pretty much any project using workers, child processes, or assets in general that are not imported or required

Victor Vlasenko

@larixer

Yes, exactly

To be fair for some situations I though myself to change this back to generate files into filesystem

At this point though it will be quite an effort

Andrew Kaiser

@andykais

I can definitely understand why in memory is better for speed and reducing clutter, but a filesystem would solve this issue, as well as being more inline with node-tap philosophy (a.k.a. you could simply run your tests files with node ./build/test)

but yes, I totally get that, its a large library now

Victor Vlasenko

@larixer

Yeah. Basically I was looking to revert back to filesystem for easier debugging, since many tools expect source maps on filesystem. They kinda support dynamic source maps, but it usually not works that well

Another thing that will work better with filesystem is running tests in parallel

You don't need to have complicated logic of sharing in memory build files between runner processes

Andrew Kaiser

@andykais

very true. How do you imagine the output would look in the build folder? Would it mimic the folder structure of the test files?

I dont know much about the internals of the project but if you want true parallelism, you would need an entrypoint for each test file plus the entrypoints in webpack.config.js and ensure that they do not collide

Victor Vlasenko

@larixer

Yes, it works like this already, but in memory, it generates entry point for each test file

The structure of files are exactly like generated by webpack

It depends on webpack config

Andrew Kaiser

@andykais

got it, so most of the work would involve changing the test runner logic

if this change ever happened, do you imagine there would be a flag for in memory vs filesystem, or would the move be purely one or the other?

Victor Vlasenko

@larixer

Thats a good question

Maintaining both would be pain in the ass

I was a long time user of mochapack already, and it worked better for me when it written everthing to disk

Andrew Kaiser

@andykais

yeah, my gut is to move it all to filesystem, but Im obviously biased :laughing:

Victor Vlasenko

@larixer

So I would drop in-memory support completely. It sounds scary - but it will be much less work, then supporting both

We can have more cautious approach and try to support both for some time and then at some point drop in-memory when we think it eats too much our time

It is not too difficult to add writing to disk, it will be actually easier, then completely droppping in-memory, since dropping in-memory will require major cleanup

Andrew Kaiser

@andykais

yup, this isnt a big deal, but if its full filesystem, developers would need to be aware that running tests will override their build directory. Its not really an issue but its something to get used to

Victor Vlasenko

@larixer

So, adding flag for using disk, sounds good for me

Actually it will not

it will change output folder to .tmp

Where communities thrive

People

Repo info

Activity