Convention for javascript repos

Development Repo Management
1

Going in the direction of JS apps we need a new convention for naming repos with js libraries allowing us to share common code. An example of such a library is https://github.com/openmrs/openmrs-contrib-uicommons which I’m intending to split that lib into 2 separate libraries:

  1. with API services like openmrsRest and openmrsTranslate
  2. with UI components (we may split that one even further down the road)

I’m asking for approval of 2 new repos:

If we were to release some library for Angular (2.x+), we could have: https://github.com/openmrs/openmrs-js-angular-api https://github.com/openmrs/openmrs-js-angular-ui

or React https://github.com/openmrs/openmrs-js-react-api https://github.com/openmrs/openmrs-js-react-ui

Does it sound right?

2 Likes
2

Overall I agree, but I’d remove the -js in the name, since I think it’s implied by angular and react.

3

(I moved this discussion to the repo-management category)

Ignoring the outliers – openmrs-core, openmrs-sdk, gpdb, and svn2git – our convention for repo names is:

openmrs :heavy_minus_sign: category :heavy_minus_sign: [ subcategory :heavy_minus_sign: ] name/id

These are the categories we have created thus far:

  • android
  • book
  • contrib
  • devops
  • distro
  • example
  • maven
  • module
  • owa
  • sdk
  • standalone
  • test

Considering adding js versus adding angularjs & reactjs to this list, I think I’d favor the latter (angularjs & reactjs), since these are by far the two buckets for js libraries these days.

Another option to consider, since most of our categories are at a higher level rather than language or specific tool (e.g., book’ and module), would be to add a category like lib for these repos.

1 Like
4

First reaction: I don’t like this. Many of these categories (module, distro, maven, owa, book) imply pretty strongly what technology is being used there. (Contrib is the outlier.) “lib” is just too broad. I’d rather have “js” because that seems like more valuable information to be communicating via the name.

I vote to keep the -js- that Rafal proposes, because it also gives us a place to put “plain JS” libraries that could exist someday. (But I’m fine if we instead go with the convention of openmrs-angularjs-, openmrs-react-, openmrs-js, etc.)

@raff I don’t love calling these things just “api” and “ui” because of the strong implication that these are the primary API and UI forever. (Maybe that’s fine and we won’t have more than one, but I’m just thinking back to the gsp days where we did uilibrary first, and then eventually replaced it with uicommons.)

5

I think this repos will contain common sources for web apps mainly JS but also It will keep some other web technologies such as HTML and CSS.

In the tech world, Hybrid Web Apps are developed with those web technologies(mainly depend on JS). So for the category naming convention, Why don’t we think about “HybridApps” or HybridWebApps"? I thought those names will describe the JS libraries perfectly. I referred about Hybrid web Apps from here.

I am new to here, So is it wrong please ignore this reply :slight_smile:

6

@suthagar23, hybrid apps is a term, which I hear often in the context of mobile apps using webview. I haven’t heard of hybrid web apps. Even though js apps may contain html, css, etc., it’s always JS that is used to glue it all together.

Okay, openmrs-angularjs-api it is.

1 Like
7

Okay, It’s good :slight_smile:

8

This got me thinking…

While I don’t like “hybrid”, I agree that it’s not actually just js, but rather a blend of web technologies. How about we call the general category “web”. E.g. openmrs-web-angularjs-api

1 Like
9

Cool with me.