Use .js/json files instead of .sh files?

[domenic]

For Windows compat and general better UX, simple key-value pairs could be stored in e.g. test/activate.json instead of in a .sh file that exports to process.env...

[kriskowal]

Understood. This can be done, but it gets a bit ugly since we still have to support the variables from process.env if process.env.TRAVIS_JOB_ID exists. I’m not sure about the workflow with the Travis gem on Windows either, but presumably we can shell out to it from a Node.js process on Windows as well.

[domenic]

Hmm I'm not sure I understand. Why do we need to support variables from process.env?

[domenic]

Oh, because that's how Travis works, of course. Well in that case I am less sure. It's probably not worth bifurcating the development workflow vs. the Travis workflow.

Closing for now unless I think of something brilliant.

[kriskowal]

I figured we might have a function like get(name) that would check for Travis and go to the environment, or fall back to reading from env.json or some such. With the current workflow, npm run test:sauce will not work because it calls out to source activate.sh, which will certainly not work on Windows.

[domenic]

I guess the alternative would be to replace it with a .js file that sets process.env.XXX = YYY. That would work in both environments.

(This is a specific instance of the more general Windows-friendly strategy of replacing shell scripts with Node scripts.)

[kriskowal]

Oh, that’d do the trick. Would have to conditionally load that module, which would work in this very specific case.

[kriskowal]

I ported the Saucelabs infrastructure to https://github.com/kriskowal/asap, but switched to using JSON for configuration, which could be encrypted for TravisCI and consumed through the environment if env.TRAVIS is defined. I intend to vend out the generalized scripts as another package, which we could then use here and in all projects in this cohort.

[domenic]

👍