Add the ability to bypass prompts by passing command line arguments #189
Conversation
Codecov Report
@@ Coverage Diff @@
## master #189 +/- ##
==========================================
- Coverage 92.84% 92.23% -0.62%
==========================================
Files 24 24
Lines 1496 1506 +10
Branches 309 310 +1
==========================================
Hits 1389 1389
- Misses 72 82 +10
Partials 35 35
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Thanks for your contribution!
I'm a bit reluctant here. I see the editor integration as a nice use-case, but I'm considering if it makes sense to expose this using another API.
If we do want to expose all the command line options we should:
- Validate the command-line options – you can easily make a mistake here)
- Add some unit test documenting that this actually works (I can help with this)
- We need to improve some of the documentation (I did some suggestions in here)
--transformershould also allow the optionall
Let me know what your primary use case are for the adding CLI arguments. Then we can try to figure out the best solution for those use cases. :)
| --parser The parser to use (babel, flow, ts, tsx) | ||
| --transformer The transformer to use (ava, chai-assert, chai-should, expect-js, expect, jasmine-globals, jasmine-this, mocha, should, tape) | ||
| --skipImportDetection Keep using the global object for assertions | ||
| --standaloneMode Use explicit require calls instead of globals |
There was a problem hiding this comment.
Use explicit require calls instead of globals -> Use explicit require calls to Jest instead of globals (not recommended unless you run the tests in a browser)
| -d, --dry Dry run (no changes are made to files) | ||
| --parser The parser to use (babel, flow, ts, tsx) | ||
| --transformer The transformer to use (ava, chai-assert, chai-should, expect-js, expect, jasmine-globals, jasmine-this, mocha, should, tape) | ||
| --skipImportDetection Keep using the global object for assertions |
There was a problem hiding this comment.
Use if your current assertion library is not required, but globally available (might result in some false positive transformations)
|
I am perfectly happy to go a different route if there is a better way to go about this, but I'd be equally happy to add some tests and better validation, whatever you think is best. Our use case is that we have a large suite of Tape tests and are migrating to Jest. Doing the transformation wholesale is not really an option, but doing them piecemeal as we update areas of the code is. The hope was that we could either share a snippet, or define a task in VSCode that would do the specific combination of transforms that we know we need, without relying on everyone to choose consistent options each time they update a test. CLI arguments was just the quickest and most portable way I could think of to do this. |
|
Thank for sharing more context here. I’m curious if you could share the size of the codebase and why moving everything wouldn’t be possible. I understand that having everything as CLI options would be nice for some projects. There are two options:
|
Users would be able to bypass all prompts by passing the options via command line. A complete example looks like this:
This allows for integration with editors and for easy consistency when doing a piecemeal conversion of an existing test suite on a large codebase.