Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 29 13:02
    larixer commented #83
  • Oct 29 12:41
    jayaddison commented #83
  • Oct 29 12:39
    jayaddison synchronize #83
  • Oct 22 09:18

    larixer on master

    Didn't work breakpoint in phpst… (compare)

  • Oct 22 09:17
    larixer closed #89
  • Oct 22 09:17
    larixer commented #89
  • Oct 22 09:16
    larixer commented #89
  • Oct 22 09:14
    t-kuni opened #89
  • Oct 20 06:38
    larixer commented #86
  • Oct 20 06:35

    larixer on v2.0.6

    (compare)

  • Oct 20 06:18

    dependabot[bot] on npm_and_yarn

    (compare)

  • Oct 20 06:18
    dependabot[bot] closed #77
  • Oct 20 06:18
    dependabot[bot] commented #77
  • Oct 20 06:18
    dependabot[bot] labeled #88
  • Oct 20 06:18
    dependabot[bot] opened #88
  • Oct 20 06:18

    dependabot[bot] on npm_and_yarn

    Bump lodash from 4.17.15 to 4.1… (compare)

  • Oct 20 06:17
    dependabot[bot] edited #77
  • Oct 20 06:17
    dependabot[bot] edited #77
  • Oct 20 06:16

    larixer on master

    Adds graceful-fs into resolutio… (compare)

  • Oct 20 06:16

    larixer on gh-pages

    Updates (compare)

Andrew Kaiser
@andykais
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

so is this something you would be able to work on?

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

if its something that makes more sense for me to pr, Ill do my best, but Im not sure I can contribute during work hours, so it may be slow going, but I am willing to give it a go!

Supremeo
@supremeo
hello all
having trouble with --watch
Victor Vlasenko
@larixer
hey
what problem?
Supremeo
@supremeo
hi victor
its not detecting changes
so basically need to kill the term and run again
using mix-laravel and vue
Victor Vlasenko
@larixer
what version of mochapack do you use ? 1.1.1 ?
Supremeo
@supremeo
"mochapack": "^1.1.1",
yep
"test:watch": "mochapack --watch --webpack-config=node_modules/laravel-mix/setup/webpack.config.js --require tests/JavaScript/setup.js tests/JavaScript/**/*.spec.js",
Victor Vlasenko
@larixer
can you try "mochapack": "1.1.0" ?
Supremeo
@supremeo
sure