Explore the feasibility of merging vue-strap into the MarkBind repository

[yamgent]

Currently, we maintain the vue-strap repository independent of the MarkBind repository.

There are some inconveniences and issues:

• A bit of labour when reviewing PRs. After building vue-strap.min.js on the vue-strap repo (the "binary" file of vue-strap), we must manually copy it into our MarkBind repo, before we can test the components.
• Because the documentation for our components are now situated in MarkBind rather than vue-strap, we must open two PRs (one in each repo) whenever we update a component
  • For example, when adding a new attribute to the component, we need to open one PR in vue-strap to update the logic, another PR in MarkBind to update the documentation.
• The original vue-strap repo is dead. It seems like there is no reason for keeping it separate anymore, since we aren't likely to receive any new updates from upstream. Also, a lot of components were purged during the migration, so our vue-strap is completely serving the interest of MarkBind, and it seems no longer appropriate to view it as a derivation of vue-strap.

Explore whether it is feasible to merge the code of vue-strap into the MarkBind repository.

Alternatively, we can also solve some of the issues above by:

• Creating a playground functionality for vue-strap.
• Creating and maintaining vue-strap as a proper npm package under MarkBind, and encourage developers to use npm link to avoid having to manually copy and paste vue-strap.min.js.
• Rebranding vue-strap. This might be a good reason to relocate the documentation back on vue-strap, while allowing us to use MarkBind syntax in those documentations.

[acjh]

No, we should not merge vue-strap into the MarkBind repository.

Actually, using MarkBind syntax in vue-strap documentation is a bad idea as it risks coupling.
It becomes difficult to see what's provided by clean UI components, versus MarkBind syntax.

It also makes it much more unlikely to receive contributions from Vue users, if they can't even build a standalone documentation.

[ang-zeyu]

Seems like I misread #981 entirely - I mistook the comment on scoped package as merging it into the repository + making it a scoped package at the same time, rather than just using npm link 🤦‍♂️

I think we should proceed with this, since the benefits listed out by @yamgent are quite numerous and some things have changed between now and then.

On receiving contributions from other users as an independent repository, I don't think that should be the goal of our vue-strap package; We shouldn't aim to compete with established libraries like bootstrap-vue. Rather, our frontend should serve our backend, and the project as a whole shouldn't be limited by keeping the repositories independent.

I didn't really get the point on coupling raised above though (it shouldn't be any more risky than it already is now), was it something from how the project was structured before?

To add,

• As we migrate more general purpose components to bootstrap-vue, more of such reusable components will be removed as well, and we are left with components tailored to fit /markbind's needs.
• ability to set up a npm run dev command of sorts with webpack and markbind serve to accomplish a live/hot reload development cycle for the frontend (extendable to even core markbind code)
  • we can certainly do so without merging it in, but /markbind does quite a bit of special processing tailored to components - panel header indexing for example. We also have some proprietary stylesheets like markbind.css that changes how things look. Hence what you put into /vue-strap might not be what you get out of /markbind.
• we've adopted a skeleton for jest snapshot testing thanks to the work in Set up jest snapshot testing for vue-strap vue-strap#146 - this puts additional overhead on the development cycle for PRs that tackle both the front and backend since we need to constantly run tests on both repos
• Having two ide windows open is generally a cognitive strain 😷 (debatable)

Merging histories wise - it should be just a matter of reshuffling the directory structure (chucking into a say, /frontend directory) in /vue-strap to merge into /markbind cleanly.

What do you guys think? @acjh @yamgent @marvinchin @le0tan @nbriannl

[acjh]

Thanks for taking the time to think about this and writing up your views on revisiting this proposal!

I didn't really get the point on coupling raised above though (it shouldn't be any more risky than it already is now), was it something from how the project was structured before?

At the time of my comment, the docs module had not been removed from /vue-strap. It was easy to build and test frontend components cleanly.

As it already is now, to test /vue-strap components, one is expected to start a MarkBind project. So we've already crossed that line.

On receiving contributions from other users as an independent repository, I don't think that should be the goal of our vue-strap package; We shouldn't aim to compete with established libraries like bootstrap-vue.

That's a false dilemma.

Receiving contributions from other users, not particularly as an independent repository, is very much one of the goals of an open source project.

The aim is not to compete, but to keep the barrier to contributing low, since a potential contributor (e.g. during Hacktoberfest) doesn't need to be bothered by how our backend plays a part.

That said..

I very much agree with you on the inconvenience faced by developers and reviewers for PRs that tackle both the front and backend.

Since we still haven't found a good solution that keeps the code separate, I'm agreeable with this.

[ang-zeyu]

Receiving contributions from other users, not particularly as an independent repository, is very much one of the goals of an open source project.

My bad should have phrased it more clearly - I meant getting other contributors to contribute to /vue-strap alone as a library of components for use in other projects. More contributors to markbind as a whole are certainly welcome 😁 On that note I likely misunderstood what you meant as well, keeping the front / backend completely separate does have benefits for a new developer seeking to contribute to just the front/backend.

Since we still haven't found a good solution that keeps the code separate, I'm agreeable with this.

Great! I think the (eventual) solution to this would be to adopt a very robust plugin api, and migrate almost all component functionality to it. When we are truly able to separate all component functionality (e.g. panel heading indexing) one way or the other, we can seek to migrate back to a new repo perhaps.

I'll get started with a pr over in /vue-strap to change the directory structure then!