Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 19 13:13
    jayaddison synchronize #83
  • Nov 14 15:49
    skjnldsv commented #83
  • Nov 14 14:55
    skjnldsv commented #83
  • Nov 07 17:44

    dependabot[bot] on npm_and_yarn

    (compare)

  • Nov 07 17:44
    dependabot[bot] commented #79
  • Nov 07 17:44
    larixer closed #79
  • Nov 07 17:44

    dependabot[bot] on npm_and_yarn

    (compare)

  • Nov 07 17:43

    dependabot[bot] on npm_and_yarn

    (compare)

  • Nov 07 17:43
    dependabot[bot] commented #80
  • Nov 07 17:43
    larixer closed #80
  • Nov 07 17:43
    dependabot[bot] commented #85
  • Nov 07 17:43

    dependabot[bot] on npm_and_yarn

    (compare)

  • Nov 07 17:43
    larixer closed #85
  • Nov 07 17:43

    dependabot[bot] on npm_and_yarn

    (compare)

  • Nov 07 17:43
    dependabot[bot] commented #88
  • Nov 07 17:43
    larixer closed #88
  • Nov 07 17:43
    dependabot[bot] commented #72
  • Nov 07 17:43
    larixer closed #72
  • Nov 07 16:41
    larixer commented #83
  • Nov 07 15:15
    skjnldsv commented #83
Andrew Kaiser
@andykais

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
Andrew Kaiser
@andykais
well thats handy!
Victor Vlasenko
@larixer
It was like this in mocha-webpack pre 1.0
Andrew Kaiser
@andykais
what was the reason for their switch to in memory? Its probably good to address that before making a revert
Victor Vlasenko
@larixer
I don't know
I have started to maintain the fork when original author was long gone
And the only info I have is the original repo
Looks like this issue was the reason to switch to in memory:
zinserjan/mocha-webpack#25
Andrew Kaiser
@andykais
gotcha, I figured it was an perf improvement
Victor Vlasenko
@larixer
yes, better they keep the original way too :)
But what is good, the patch is not that big:
https://github.com/zinserjan/mocha-webpack/pull/83/files
So by reading this patch it is possible to add back old behavior too
It is much better than adding writing to disk from scratch
Andrew Kaiser
@andykais
yeah thats a very good point