<     May 2017     >
Su Mo Tu We Th Fr Sa  
    1  2  3  4  5  6  
 7  8  9 10 11 12 13  
14 15 16 17 18 19 20  
21 22 23 24 25 26 27  
28 29 30 31
00:13 kingarmadillo joined
01:08 hcpl1 joined
01:32 tkimball_ joined
02:19 BlueProtoman joined
02:19 <BlueProtoman> Is there a way I can test a Travis file locally (using a Dockerfile or something) so I don't have to keep making stupid little commits?
02:27 kingarmadillo joined
03:06 <ljharb> BlueProtoman: test it on a temp branch, and squash it down when it's good
03:06 <ljharb> no reason you have to test it on a branch that matters
03:06 ZyX-I joined
03:28 kingarmadillo joined
03:33 <BlueProtoman> ljharb: I don't want to have to keep waiting for Travis each time.
03:35 <ljharb> BlueProtoman: http://lint.travis-ci.org ?
03:35 <ljharb> that checks straight validity; but to test what different valid configs actually do, you just have to wait
03:38 <BlueProtoman> ljharb: That's a nice tool, it really is, but it's not what I'm looking for...
03:38 <ljharb> it's the official travis tool to ensure a travis file is valid ¯\_(ツ)_/¯ not sure what else you'd want
03:39 <ljharb> if you want to see how the matrix plays out, you don't have to wait for anything - it shows you that more or less instantly, and you can just cancel the build
03:39 <ljharb> the only thing you'd have to wait for is results, and obviously you can't get those without actually running the tests
04:59 lpin joined
05:03 ZyX-I joined
05:28 tkimball joined
05:29 kingarmadillo joined
05:31 canvon joined
06:30 f32 joined
06:30 <f32> ljharb: heya
06:31 <f32> ljharb: got setup, have a simple node prog with a simple test, builds passing, looking for how to pubish
06:36 <ljharb> great
06:36 <ljharb> ok so remind me what constitutes "publishing"
06:56 <f32> ljharb: oh, just deployment
06:56 <f32> ljharb: sorry, currently, i have a .travis.yml setup for node, and it appears that travis is running the npm "test" command
06:56 <ljharb> ok, but what'd you land on - "scp to your server", "curl to a URL"?
06:57 <ljharb> yes, that's what it's supposed to do by default
06:57 <ljharb> and regardless of what you have travis do, `npm test` locally should be sufficient to run all the tests
06:57 <ljharb> you can use the "script" key in travis.yml to override what command it runs
06:57 <f32> ljharb: what is the mechanism to override this, id like to run a bash script to test
06:58 <f32> ljharb: oh, so script: \n tsc [build] && node bin/tests ?
07:00 <ljharb> yep
07:00 <ljharb> altho
07:00 <ljharb> what you really want is that `npm test` runs that tsc command
07:00 <ljharb> meaning, you should add that to the "test" script in package.json
07:01 <ljharb> you can even do `"test": "node bin/tests", "pretest": "tsc [build]"`
07:01 <f32> ljharb: things are a bit awkwards with typescript
07:01 <ljharb> it can get very clean
07:01 <ljharb> either way, whatever awkwardness has to go somewhere, and you really want package.json's "scripts" to be the entry point to the sole source of truth
07:01 <f32> ljharb: normally what i do is i have package.json as a asset that gets copied into the /bin during a build
07:01 <ljharb> ie, it can call a shell script, and that's fine
07:02 <ljharb> hm
07:02 <ljharb> i wouldn't consider package.json as an asset
07:02 <f32> ljharb: my typical setup is...
07:02 <ljharb> it's project metadata
07:02 <f32> ./package.json
07:02 <f32> ./src/[tssource]
07:02 <f32> ./bin/[compiled source] + [package.json]
07:02 <ljharb> ok so that exactly mirrors everyone else's babel setup, except for the package.json.
07:02 <f32> ljharb: so, when i publish to npm say, i publish out of the ./bin
07:03 <ljharb> right, you don't do that - you publish out of the root
07:03 <ljharb> every command *always only* gets run in the root.
07:03 <ljharb> you can use npmignore to prevent publishing the src (if you want, but it's ok to publish it) and your package.json's "main" should point to the entry point inside bin
07:03 <f32> the root contains typescript tho, i don't want to publish typescript to npm, just the compiled output
07:03 <ljharb> that's fine, use npmignore for that.
07:04 <f32> hmmm, alright
07:05 <ljharb> (i mean obv you can do whatever you want; i'm describing the most common/best/most typical way it's done)
07:05 <f32> no, im all ears
07:05 <ljharb> word
07:05 <f32> so ok, publish to npm from the root, add a .npmignore to not publish the ./src
07:05 <ljharb> yep! one caveat tho
07:05 <f32> keep package.json in the root
07:05 <ljharb> to start your npmignore - duplicate your gitignore
07:06 <ljharb> because npm ignores your gitignore if there's an npmignore present
07:06 <ljharb> (sadly it won't merge the two)
07:06 <ljharb> otherwise, spot on
07:06 <f32> ljharb: and with regards to the actual module that winds up on npm, id need to specify in the package.json where the entry point is right?
07:07 <ljharb> yes
07:07 <f32> ./package.json
07:07 <ljharb> the key is "main"
07:07 <f32> ./bin/compiled_stuff
07:07 <ljharb> and the value is the relative path to your thing
07:07 <ljharb> right
07:07 <ljharb> "./bin" if it's bin/index.js
07:07 <ljharb> "./bin/foo" if it's bin/foo.js
07:07 <ljharb> etc
07:07 <f32> ljharb: it is index.js yes
07:07 <ljharb> (always omit extensions for code when possible in requires, it aids refactoring)
07:07 <f32> ljharb: i typically just rely on having a index.js when publishing from ./bin
07:08 <ljharb> that's fine
07:08 <ljharb> then your "main" can also just be "./bin"
07:08 <ljharb> so it'd end up working the same
07:08 <f32> ljharb: ok that is all good, but can we talk about require() ?
07:08 <ljharb> sure
07:08 <f32> i assume when require'ing a module, require attempts to load the package.json (if available) and looks for "main" right?
07:09 <f32> ljharb: bear with me, i don't normally approach things this way
07:11 <ljharb> require has a complex algorithm
07:12 <ljharb> when it hits a directory, it does look for a package.json's "main" if present
07:12 <f32> ljharb: right, that is something i should know
07:12 <ljharb> if the file is but "main" is not, it defaults to "index.js", iirc
07:13 <ljharb> f32: https://github.com/substack/node-resolve is a JS implementation of it; https://nodejs.org/api/modules.html#modules_all_together is the official docs for it.
07:14 <f32> ljharb: thanks, i think im fine with using "main" to describe the module entry point, and .npmignore is a good thing
07:14 <f32> ljharb: interestingly, i think typescript might even inspect package.json
07:14 <ljharb> (on a separate note; in general i think it's totally fine to publish `src` to npm - people who don't want it won't see it, people who do want it will benefit)
07:14 <ljharb> yes, typescript probably does
07:14 <ljharb> i'm sure there's some special "main:ts" key or something it looks for, that you could use to point to `src`
07:14 <ljharb> that way, typescript users would get bonus features.
07:15 <ljharb> (but you'd have to publish the source, and configure it properly, for that to work)
07:15 <ljharb> i don't use TS so i'm not sure of the technique
07:15 <f32> ljharb: i have some project refactoring to consider to bring my projects inline with travis
07:15 <ljharb> fair
07:16 <f32> ljharb: for what its worth, i do actually bundle my npm modules
07:16 <ljharb> like, roll all the files up into one?
07:16 <f32> yeah
07:16 <ljharb> ok so that has pros and cons
07:16 <f32> at a package level i do yeah
07:17 <ljharb> pro: your public API is explicitly restricted, such that "private" code in your file is truly so. that's the *only* way to make things unreachable while still having separate files.
07:17 <f32> i don't try and bundle the dependent modules of course, but i like to visualize things as .net assemblies, and bundling allows me to have true private types
07:17 <ljharb> cons: nobody can ever deep-require pieces they need, thus loading less code and bypassing the whole thing; if you have any conditional requires, no filesize is saved, etc
07:17 <ljharb> right, i agree that's a benefit.
07:18 <ljharb> it's not common in the JS ecosystem to do it. but it's not, like, bad or anything imo
07:18 <ljharb> but def not automatically good.
07:18 <f32> ljharb: it seems kinda bad to require into a specific piece of code tho
07:18 <ljharb> for things that could get sent down to a browser, allowing consumers to be able to tree-shake and dead-code-eliminate is helpful.
07:18 <ljharb> it depends on the project
07:19 <f32> yeah, i guess
07:19 <ljharb> for lodash, `require('lodash/omit')` for example is the recommended way to do it.
07:19 <ljharb> because why parse and load code into memory if you don't need it?
07:19 <f32> ljharb: well, if it only happens once, im fine with it
07:20 <ljharb> yeah but your users may not be :-)
07:20 <ljharb> anyways it's a fine choice.
07:20 <f32> ljharb: im used to waiting for .net to JIT and start
07:20 <ljharb> either way tho your build process can make it so `index.js` is the only file inside `bin`
07:20 <ljharb> i would strongly discourage thinking about node and JS the same way as .net
07:21 <ljharb> i do realize typescript makes that easy
07:21 <f32> ljharb: it doesn't really
07:21 <ljharb> but typescript or not, JS isn't C#/.net and won't ever be
07:21 <f32> ljharb: well, you would be suprised the parity
07:21 <ljharb> lol k, it seems to bring in lots of its idioms, but ¯\_(ツ)_/¯ not my area
07:22 <ljharb> anyways i gt run, hopefully this is enough to get you started
07:24 <f32> thank you ljharb
07:26 <ljharb> np, gl
07:30 kingarmadillo joined
08:09 <f32> ljharb: yes, just followed your advice, things are indeed a lot cleaner now
08:09 <f32> thank you very much
08:58 ski7777 joined
09:33 kingarmadillo joined
10:53 hcpl2 joined
10:56 adw1n joined
11:34 kingarmadillo joined
12:09 ski7777 joined
12:32 travis-ci joined
12:32 <travis-ci> javierbonillad/node.js#1 (master - b33577e : Javier Bonilla): The build passed.
12:32 <travis-ci> Change view : https://github.com/javierbonillad/node.js/compare/dcdfff5b8656...b33577e49cbc
12:32 <travis-ci> Build details : https://travis-ci.org/javierbonillad/node.js/builds/236659599
12:32 travis-ci left
12:32 eregon joined
12:39 npmccallum joined
13:19 ZyX-I joined
13:35 kingarmadillo joined
13:47 hcpl2 joined
14:13 rickmak joined
14:31 rickmak joined
16:03 adw1n joined
16:50 travis-ci joined
16:50 <travis-ci> javierbonillad/node.js#1 (master - b33577e : Javier Bonilla): The build passed.
16:50 <travis-ci> Change view : https://github.com/javierbonillad/node.js/compare/dcdfff5b8656...b33577e49cbc
16:50 <travis-ci> Build details : https://travis-ci.org/javierbonillad/node.js/builds/236659599
16:50 travis-ci left
16:52 travis-ci joined
16:52 <travis-ci> javierbonillad/node.js#2 (master - 14a65c6 : Javier Bonilla): The build passed.
16:52 <travis-ci> Change view : https://github.com/javierbonillad/node.js/compare/b33577e49cbc...14a65c632e5d
16:52 <travis-ci> Build details : https://travis-ci.org/javierbonillad/node.js/builds/236707531
16:52 travis-ci left
17:33 tkimball joined
18:17 hcpl2 joined
18:20 kingarmadillo joined
18:32 kingarmadillo joined
19:18 Rotwang joined
19:18 <Rotwang> Hello!
19:18 <Rotwang> Just a quick question.
19:19 <Rotwang> I've found out that you can encrypt stuff in your travis configuration yaml like this: https://docs.travis-ci.com/user/encryption-keys/
19:19 <Rotwang> Question: where is the private key stored and who has access to it?
20:20 kingarmadillo joined
20:28 tkimball joined
20:51 ZyX-I joined
21:48 travis-ci joined
21:48 <travis-ci> MichelML/bbpr#78 (master - 2cad30c : MichelML): The build passed.
21:48 <travis-ci> Change view : https://github.com/MichelML/bbpr/compare/047c9870bd37...2cad30cabdaa
21:48 <travis-ci> Build details : https://travis-ci.org/MichelML/bbpr/builds/236762833
21:48 travis-ci left
21:50 travis-ci joined
21:50 <travis-ci> MichelML/bbpr#79 (master - d99898d : MichelML): The build passed.
21:50 <travis-ci> Change view : https://github.com/MichelML/bbpr/compare/2cad30cabdaa...d99898dd72af
21:50 <travis-ci> Build details : https://travis-ci.org/MichelML/bbpr/builds/236763210
21:50 travis-ci left
22:14 kus joined
22:25 kingarmadillo joined
22:55 Gankro joined
22:57 albanc joined
22:57 nz joined
22:58 MJD joined
23:00 Callek joined
23:07 Nooby joined
23:26 kingarmadillo joined