Frederik Ring

I think the overall structure makes a lot of sense like this. > For this to work, we need to add frontmatter to the README files. If this is something...

> This way the readme files can have different content than the website. I'm not entirely sure I understand this. Would this mean we would have a README in the...

> We could, alternatively, generate the content from a set of entirely different markdown and template files. How about we start by having everything in `site` but symlinking the existing...

How would that work for someone who's trying to publish a new version of say a driver? Would you ``` npm run version -- -w driver-puppeteer ```

> npm version patch -w cli Ah ok, now I start to understand what the PR in `changes` actually does and it seems to make sense. Would a "release every...

By now I also feel that a project of this scale is better off releasing modules individually. I do like the convenience aspect of "same version number all over" as...

On more question for my understanding about the peer dependency handling: In case we release a new major version of `@mochify/mochify`, each driver would have to release a new version...

So https://github.com/GoogleChrome/puppeteer/issues/3652 got closed and it seems that it should now be possible to run tests against Firefox too (I also think :tm: I just got a test passing on...

I looked into this a little further. Upgrading to Puppeteer 5 seems to work with two caveats: - we'd have to drop Node 6 and 8 - Puppeteer now uses...

> But if it's too brittle, it can wait, I think. I totally share that sentiment. I can keep an eye on how the Firefox integration in Puppeteer evolves and...