Improve development workflows

[jooola]

So, I've been proposing a few PR to this project, and I feel I could bring some improvement in the development workflows.

I open this ticket to open a discussion on the few ideas.

Here are some thoughts:

• Improve the Github CI by :

  • Start enforcing code formatting and linting (Huksy will help on the developer side)
  • Simplifying the testing setup, less scripts, less duplicate code, use tools (See Selenium Grid below)

• Improve the Issue tracker by:

  • Adding issues templates for different topics with automatic labeling (i18n, bug, feature, ...)
  • Adding a stale bot to close old inactive issues

• Improve Coding by:

  • Cleaning up old files, adding more documentation
  • Defining a coding convention for the repository (https://google.github.io/styleguide/jsguide.html ?)

• Simplify Testing by:

  • Reduce number of testing framework and choose one (Jest ?)
  • Integrate with Selenium Grid instead of Sauce labs for cross browser testing (which seems not to be in use right now ?)

I know the project is on the move to typescript, and I would prefer not to mess too much with the code base while everything is being migrated, but the main goal is to have a clean and efficient repository by the time v3 is released.

[kossnocorp]

Hey! I appreciate the effort, but I'm not in favor of taking on such a massive plan, especially when we focus on TypeScript migration. We've been through something like that with v1 -> v2, and it was a nightmare that I don't want to repeat.

Besides that, I have strong concerns regarding this plan. I don't want to dismiss everything at once and want to give you a chance to elaborate, so if you're interested in the discussion, please address these:

Start enforcing code formatting and linting (Huksy will help on the developer side)

Please elaborate. We already have both. As you might notice, we're in the middle of Prettier migration, and there's still code that's not formatted with it. We can't format the whole codebase and not create more work by breaking pull requests. I also don't see any rush. The current approach where Husky formats the changed code works just fine.

Simplifying the testing setup, less scripts, less duplicate code, use tools (See Selenium Grid below)

I don't get what do you mean by that. Please be concrete.

Adding issues templates for different topics with automatic labeling (i18n, bug, feature, ...)

That's would be a great addition, but it should be coming from us as we see the bigger picture. @tan75 could you please look into that?

Adding a stale bot to close old inactive issues

From my experience, it just annoys people. I don't see any good reason to add that.

Cleaning up old files, adding more documentation

Do you have any concrete points? This is way too abstract.

Defining a coding convention for the repository (https://google.github.io/styleguide/jsguide.html ?)

I'm against any conventions that we can't automate. Creating and then enforcing conventions, it's just too much work for no good reason. We don't work on the same scale as Google for it to be a problem.

Reduce number of testing framework and choose one (Jest ?)

Using both Jest and Karma allows us to run tests both in Node.js and browsers. Could you please explain your motivation and how it would be better?

Integrate with Selenium Grid instead of Sauce labs for cross browser testing (which seems not to be in use right now ?)

I don't understand how it should work. Sauce Labs allows us to run Karma tests, while for Selenium we would have to adapt or rewrite tests (right?).

As I said, I hate the idea of increasing the scope of the release especially given that we would have to rework docs and Flow typing generation, and improving any scripts will surely interfere with that. But we welcome isolated improvements on the things we'll find common ground.

[jooola]

I am all for cherry picking what is best for the project.

Most of what is written here are assumptions from a new contributor that had some troubles while developing. I don't know how it works, either because I missed some things, or it is too complex, or undocumented .

Hey! I appreciate the effort, but I'm not in favor of taking on such a massive plan, especially when we focus on TypeScript migration. We've been through something like that with v1 -> v2, and it was a nightmare that I don't want to repeat.

Yes the idea is not to mess the repository, but adding some small changes that can improve greatly some workflows. Some ideas can get big, but they can be ignored.

Besides that, I have strong concerns regarding this plan. I don't want to dismiss everything at once and want to give you a chance to elaborate, so if you're interested in the discussion

I appreciate that.

Start enforcing code formatting and linting (Huksy will help on the developer side)

Please elaborate. We already have both. As you might notice, we're in the middle of Prettier migration, and there's still code that's not formatted with it. We can't format the whole codebase and not create more work by breaking pull requests. I also don't see any rush. The current approach where Husky formats the changed code works just fine.

Currently the husky setup ignores completely files other than *.js, so since the migration to typescript started, files aren't format.
This PR #2319 tries to improve that, but as we discussed on that PR, we cannot enforce developers to run husky on there code.
I assumed it would be enforced in the CI, but I don't see any formatting check in the GitHub Workflows.

I see yarn lint (eslint .) being run in the CI script, but it doesn't seem to work ?

So the proposal is to start enforcing code formatting using the CI and suggest devs to enable husky in there repository.

Simplifying the testing setup, less scripts, less duplicate code, use tools (See Selenium Grid below)

I don't get what do you mean by that. Please be concrete.

I mainly spotted 4 almost identical workflow files used to test the repository, I though this could be improved, and speed up.

It could also be split into smaller and more descriptive jobs and put in proper pipeline : (checking, linting), (building), (testing), (release)?, (deploy)?

Adding issues templates for different topics with automatic labeling (i18n, bug, feature, ...)

That's would be a great addition, but it should be coming from us as we see the bigger picture. @tan75 could you please look into that?

👍

Adding a stale bot to close old inactive issues

From my experience, it just annoys people. I don't see any good reason to add that.

Fair enough, I was simply hoping the add movement to old issues, for instance issues pre v2, in order to get people to close by themself, or give some update on the status of the ticket.

Defining a coding convention for the repository (https://google.github.io/styleguide/jsguide.html ?)

I'm against any conventions that we can't automate. Creating and then enforcing conventions, it's just too much work for no good reason. We don't work on the same scale as Google for it to be a problem.

I agree it is difficult to enforce, but having a conventions where you can find information on how the code should look like is a good idea.

Constants should be in uppercase is a good convention in my opinion. It gives users of this library an additional information of the tool they are using. This is why I suggested to change the maxTime constant to MAX_TIME.

Also I asked here #2318 (comment) how should I write the function option argument, this kind of questions could be answered in a conventions for this project.

Integrate with Selenium Grid instead of Sauce labs for cross browser testing (which seems not to be in use right now ?)

I don't understand how it should work. Sauce Labs allows us to run Karma tests, while for Selenium we would have to adapt or rewrite tests (right?).

I though the Sauce labs tests are not working ? https://github.com/date-fns/date-fns/blob/master/config/karma.js#L148-L149
So I proposed to use Selenium Grid instead, which is free to use, and could reduce some costs. I admit I don't know perfectly how Selenium work, so regarding a rewrite of test I don't know.