Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Project Health #555

Open
7 of 18 tasks
stevekrouse opened this issue May 17, 2019 · 2 comments
Open
7 of 18 tasks

Project Health #555

stevekrouse opened this issue May 17, 2019 · 2 comments
Assignees

Comments

@stevekrouse
Copy link
Owner

stevekrouse commented May 17, 2019

  • tests
    • research testing system
    • ensure .es6 == .js
    • ensure .es6 is style is good (prettier), pre-commit test?
    • web based automated testing?
    • tests for core Add tests for woofjs core library #328
    • tests for /create
  • benchmark speed load times & remove bloat
  • build system research
    • figure out package-lock story
    • js style autoformat such as prettier
    • typescript research
    • research directory structure to split up /create into files
    • abstract /create & /team
    • benchmark & minification
  • refactor
@stevekrouse stevekrouse created this issue from a note in WoofJS Development (Priority 1) May 17, 2019
@stevekrouse stevekrouse moved this from Priority 1 to In Progress in WoofJS Development May 17, 2019
@stevekrouse stevekrouse self-assigned this May 17, 2019
@stevekrouse stevekrouse pinned this issue May 20, 2019
@stevekrouse
Copy link
Owner Author

Testing

Everyone seems to think testing is a good idea. Yet in my experience it takes a lot of time (50%), doesn't catch many bugs, and we still have to manually run things anyways. Of course this is only true on small projects with small user bases.

I think my policy will be that instead of testing everything, let's only put tests in place for things that break once. Yes this will require our users to be our bug testers, but I think that's ok as long as we can rollback quickly and fix bugs quickly.

In other words, let's not pre-optimize here. Let's see if we create too many problems first before over-engineering our testing suite.

If we do decide to add testing, cypress.io looks neat! These are the standard options: mochajs.org, jestjs.io

@stevekrouse
Copy link
Owner Author

Simple Tests & Formatting

  1. What would make everyone's life easier is if we were guaranteed that .es6 == .js. This could be a pre-commit hook, but that would require installation. It could be a test we run on pull request, but it could also be a job run on pull request to do it for you automatically and submit as a commit for you.

  2. Another idea that will make everyone's life easier is automatic prettier formatting. Again this can happen on save, as a precommit hook, or as a bot that criticizes you or does it for you.

Seems like the pre-commit hook is the standard way for prettier

I found this bot restyled.io but it didn't seem to do what I wanted...

I could make my own bot like I did for the Zapier rawgit/githack thing with Probot https://probot.github.io/

Travisci or Circleci could be helpful here too...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

1 participant