You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Having just started to work on pileup.js, I'm trying to understand the best workflows to use. Some snags I've hit that imply questions about whether there are better ways:
there doesn't seem to be a way to just compile a few files, rather than running a full npm run build.
some tests can be run as "unit-tests" (e.g. mocha dist/main/…), others require phantom.js machinery / XHRs, and there's no obvious delineation between the two.
in some cases we really should just mock out the XHRs, too; the BigBed tests for example hard-code loading over HTTP requests but that seems like overkill for what is logically some parsing-logic tests.
the XHR-requiring tests can not be iterated on and run without a full npm run build && npm run test, afaict.
npm run test ignores parameters that filter which tests should run, e.g. -g <test name> which works for cmdline mocha invocations.
babel seems to recompile all files, even if they've not changed.
Any thoughts on any of these? I have a scripts/babel.sh locally that lets me babel specific files, for iterating on tests that are unit-test-able per the first two bullets above, but it seems like there's a lot of room for some workflow-management logic to improve life here. I'm not current on what the JS ecosystem provides for such but wanted to start the discussion.
The text was updated successfully, but these errors were encountered:
There is an npm run watch command which will do incremental builds on both the main bundle and the tests. If you're interested in type checking as you edit, Flow has a server that you can start up.
re: tests which can be run from the command line using mocha. If that works for any tests, then it's entirely unintentional. pileup.js is designed to be run in a browser, not node.js. So it should be tested in a browser. We did cycledash testing on the command line using mocha and node and ran into all kinds of headaches mocking out the DOM, XHR and jQuery in ways that were compatible with node's module loaders.
re: running specific tests, there's a command in README.md. (npm run test -- --grep=pileuputils, note the extra --.) You can also click a test / suite name in the Mocha test runner to only run that test / suite (it'll add an ?grep= bit to the URL).
Glad to see you all the work happening in this repo! :)
Having just started to work on pileup.js, I'm trying to understand the best workflows to use. Some snags I've hit that imply questions about whether there are better ways:
npm run build
.mocha dist/main/…
), others require phantom.js machinery / XHRs, and there's no obvious delineation between the two.npm run build && npm run test
, afaict.npm run test
ignores parameters that filter which tests should run, e.g.-g <test name>
which works for cmdlinemocha
invocations.Any thoughts on any of these? I have a
scripts/babel.sh
locally that lets me babel specific files, for iterating on tests that are unit-test-able per the first two bullets above, but it seems like there's a lot of room for some workflow-management logic to improve life here. I'm not current on what the JS ecosystem provides for such but wanted to start the discussion.The text was updated successfully, but these errors were encountered: