search

bufferapp / buffer-extension-shared

Shared code between Buffer extensions
MIT License
21 stars 13 forks source link

How's this working out for y'all? #55

Open tgvashworth opened 9 years ago

tgvashworth commented 9 years ago

Hey Buffer peeps! This is gonna seem like a weird issue, but I'm interested to find out how you find the workflow here — the shared repo, submoduled out to the wrapper repos.

What would you change about it? How much maintenance do you have to do on the wrappers vs this repo?

Any and all thoughts welcome!

djfarrelly commented 9 years ago

hey @phuu, I recognize that handle from many commits!

tl,dr: the overhead of the nested repos now seems to outweigh the benefits of keeping the code compartmentalized. Starting over clean, I'd personally try a different approach.

Working with the extension for over a year, I have a bit of experience working with the nested repos. While it is cool and keeps specific logic separated, it has felt like it can slow down the dev + release flow a bit. I added a few extra grunt tasks to help script up common tasks. Most of the changes happen in the shared repo, but more and more with changes to Firefox and fixing browser specific bugs, it's a mixed bag.

If I started from a clean slate, I would drop this shared repo (maybe even move to one big repo), keeping the shared folder at the same directory level as the browser repos and use a Gulp/Grunt watch task and Browserify or Webpack to build and copy all the necessary files into each browser's sub-repo.

Hope that helps out a bit!

tommoor commented 9 years ago

To chime in ... because, why not?! If I was to tackle this again now I'd probably extract the shared logic into a few neat components in separate repo's and use npm / browserify type workflow to require them into each. Grunt/gulp certainly would have made our lives easier back when this began.