Skip to content
This repository has been archived by the owner on May 7, 2021. It is now read-only.

[Tracker] refactor npm scripts #2376

Open
debloper opened this issue Dec 21, 2017 · 3 comments
Open

[Tracker] refactor npm scripts #2376

debloper opened this issue Dec 21, 2017 · 3 comments

Comments

@debloper
Copy link
Contributor

debloper commented Dec 21, 2017

While the npm-scripts that we have in Planner repo is pretty lean, and is limited bunch of commands - it never hurts to have a preset plan to make them more manageable and cope with further addition of capabilities without bloating it up.

Right now, the scripts' block looks like this:

    "build": "gulp build",
    "build:library": "gulp build:library",
    "watch:library": "gulp watch",
    "clean:dist": "gulp clean:dist",
    "clean:all": "gulp clean:all",
    "reinstall": "rimraf node_modules && npm --force cache clean && npm install",
    "test:unit": "gulp test:unit",
    "semantic-release": "semantic-release pre && gulp build && cp -r .git dist && npm publish dist/ && semantic-release post"

The necessary and sufficient primary tasks (primitives, not specialized) that we need, would be:

  • clean
  • setup
  • build
  • test

Let's spare describing them as they should be pretty self explanatory.

In order to work with specialized tasks (clean:all or test:unit and the likes of them), how about we use minimist or yargs with gulp (which we already use), and pass the specialization factors as parameters to the main script (which npm allows with --).

This will allow us to abstract away the specific commands from package.json as well as where we use them, leaving only the task handlers (and in some cases parameters). The specifics of how the task is run and which tools are used/replaced will have no impact on them, as long as they can take the command+param and execute it.

@debloper
Copy link
Contributor Author

debloper commented Dec 21, 2017

To further expand the command primitives with some initial set of modifier parameters:

  • clean
    • all (default)
    • cache
    • config
    • dist
    • images
    • modules
    • temp
  • setup
    • env
    • new
    • refresh (default)
    • devops
  • build
    • app (default)
    • image
    • release
    • tarball
    • validate
    • watch
  • tests
    • coverage
    • func
    • quality
    • security
    • unit (default)

UPDATE: revisit setup tasks when we have need for it. At the moment it seems like abstraction tasks done at lower level and conflicts with the concept. Setup related tasks can/should be done at Makefile level. All the lower level routines to make that possible are to be defined in gulp.

@nimishamukherjee
Copy link
Collaborator

@debloper how is this different from what we already have?
Functional tests do not run in planner.
Only unit tests run in planner.

@debloper
Copy link
Contributor Author

debloper commented Jan 12, 2018

@nimishamukherjee as discussed, this:

  • compartmentalizes and delegates task-management to task runners and does so more efficiently
  • allows scaling up (expanding with new subroutines) without messing with npm/package.json
  • allows parametric subroutines (--param or --param=value to base tasks) for better control
    • that also means we can now do task overloading, as in npm run clean --cache --modules instead of npm run clean:modules && npm run clean:npmcache
  • layers better with gulp -> npm -> make projected model of abstraction (work in progress)

In addition tho those, as good-to-have, it also

  • allows drop-in replacement of tools (e.g. from gulp to grunt)
  • keeps package.json clean and nonchalant to the tasks
  • adds no overhead compared to the existing process

Also, about the tests - you are correct at this point in time. But once we're done with standalone-planner, we need to accommodate for Functional tests as it's not only a library anymore, but a full user facing app.

It's given, that some of the parameters mentioned there are far into the future (coverage, code quality, security tests etc), but by design this system already makes space for it when it needs to be implemented.

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

No branches or pull requests

2 participants