These are chat archives for Munter/fusile

20th
Oct 2015
Oskar
@oskarrough
Oct 20 2015 07:47
Morning, anyone here?
Peter Müller
@Munter
Oct 20 2015 08:30
Yes
@oskarrough What's up?
Oskar
@oskarrough
Oct 20 2015 08:38
I'm tired of setting up tons of compilers with gulp/grunt/… so I wanted to learn more about the Fusile idea… I got it running and it autocompile which is great. One question, how do you build everything for deployment? Or is the idea that everything in the mounted folder is ready to go?
Peter Müller
@Munter
Oct 20 2015 08:39
Never use this in production, so certainly don't mount this on a public facing server
So obviously you need a production build
The simplest one is cp -r mount dist
You probably want to do more work after that if you have other tools to bundle, minify or similar
Oskar
@oskarrough
Oct 20 2015 08:41
where mount is the path to the mounted fuse drive?
Peter Müller
@Munter
Oct 20 2015 08:41
If you need this running on a CI server, which has little benefit from the whole caching infrastructure you might want to peek under the hood and skip the fuse mount part
Exactly
Oskar
@oskarrough
Oct 20 2015 08:42
I'm basically just exploring how we could improve our setup as I'm growing tired of managing tons of build tasks
Currently we have gulp tasks that watches, compiles and servers which is the same as Fusile, right. So how would you say the differ in approach? I mean, what is the difference if it's a fuse drive or an ordinary .tmp folder?
Or is the advantage that everything compile automatically based on file types?
no worries if you don't have time now of course :)
Peter Müller
@Munter
Oct 20 2015 08:43
My ideal setup at the moment would be fusile below systemjs for devlopment. Possibly with an image pipeline as a middleware in between. For production build I'd like to use Assetgraph and nothing else
The main difference between fusile and a task runner with a .tmp folder is the control flow
Task runners will watch the files and do work whenever the file updates. Fusile won't do any work until you start accessing the file
The inverted control flow is also what gives fusile enough context to do away with all the path configuration that you'd normally need in task runner setups
Did you see my talk at jsconf.eu?
Oskar
@oskarrough
Oct 20 2015 08:46
Ah, alright thanks. Nop didn't make it this year unfortunately - is it online?
Peter Müller
@Munter
Oct 20 2015 08:47
It went online yesterday. They haven't done promotions of it yet. https://www.youtube.com/watch?v=MptY6ff4tOQ
Oskar
@oskarrough
Oct 20 2015 08:47
ah great thanks
Peter Müller
@Munter
Oct 20 2015 08:47
I spend a lot of time here talkign about the differences. No time on setting up complete workflows
Oskar
@oskarrough
Oct 20 2015 08:47
we said hi to each other at reject.js one or two years ago very very briefly
Great, I'll check it out
Peter Müller
@Munter
Oct 20 2015 08:56
If you do a live reloading setup I think the best setup is most likely to put file watchers on your source files instead of the fuse mount. I am currently trying to be clever about file watchers inside fusile, but it feels bad and really doesn't cover all the use cases. I might pull that out again at some point. Not really a problem, since watching the source file and triggering an update in the browser will still hit the file on the fuse mount, which will then be recompiled
Oskar
@oskarrough
Oct 20 2015 09:56
Well that would be cool. Set up browser-sync myself and reload browser then fusile does the rest?
Peter Müller
@Munter
Oct 20 2015 10:53
Pretty much. As soon as the browser knows it needs to reload an asset, that request will eventually hit fusile and complete the circle
Of course, compared to a gulp setup the transpiler work will be done after all the requests have triggered isntead of before. Might give a delay of a few ms extra. Haven't measured that
Dave Jeffery
@davej
Oct 20 2015 20:25
Made a start on a middleware version: https://github.com/davej/piggy-in-the-middle
Peter Müller
@Munter
Oct 20 2015 20:26
@gustavnikolaj you might want to get in on this
Dave Jeffery
@davej
Oct 20 2015 20:26
Would be nice to see if there are modules that could be shared between the two. Tolk is the obvious example but also caching and source file error reporting.
Peter Müller
@Munter
Oct 20 2015 20:28
I haven't found a good way to abstract away the cache yet. The error rendering might be possible to pull out into a standalone module
Dave Jeffery
@davej
Oct 20 2015 20:29
Yeah, I'll take a look through fusile when I get the chance and see if there are abstractions that can be shared.
Peter Müller
@Munter
Oct 20 2015 20:30
My approach to error reporting might seem a bit controversial
Dave Jeffery
@davej
Oct 20 2015 20:30
Ha, why is that?
Peter Müller
@Munter
Oct 20 2015 20:30
I'm basically destroying any page the asset is included on in order to show a very obvious error message in the browser
It's all just styling of course.
Dave Jeffery
@davej
Oct 20 2015 20:31
Like an overlay or something?
Peter Müller
@Munter
Oct 20 2015 20:31
I found it highly beneficial in the livereloading case to get instant feedback on errors. And I have a tendency to not look in the dev servers logs all the time
Dave Jeffery
@davej
Oct 20 2015 20:33
Yeah, your using the content property that's basically what I was doing
I used a fixed position overlay at the top of the page
(Not in PITM but in the middleware I was working on before)
Peter Müller
@Munter
Oct 20 2015 20:34
fusile has wrappers that do the same for js and html
Those should probably be extracted
Dave Jeffery
@davej
Oct 20 2015 20:35
Oh right, how does that work for js?
Peter Müller
@Munter
Oct 20 2015 20:35
a script injects the same css overlay, but also puts the stack trace, or whatever error is available, in the console
Dave Jeffery
@davej
Oct 20 2015 20:36
ok, cool. Doesn't sound too controversial to me.
Obviously not good for production but perfect for dev
Dave Jeffery
@davej
Oct 20 2015 20:38
When you say that it outputs the error in console do you mean the node console or the browser console?
Peter Müller
@Munter
Oct 20 2015 20:39
Browser console. But it seems I forgot to add that part in. I was sure I did that :)
Dave Jeffery
@davej
Oct 20 2015 20:39
Yeah, browser console is what I did too :-)
Peter Müller
@Munter
Oct 20 2015 20:39
For fusile it would make sense to also duplicate these in the node console.
Dave Jeffery
@davej
Oct 20 2015 20:40
yup for sure
Cool, when I work on the source file syntax error stuff, I'll try and keep it modular and keep fusile in mind
Perhaps we can share the modules then
Peter Müller
@Munter
Oct 20 2015 20:42
I'll pull out the js error and html error module snow
Dave Jeffery
@davej
Oct 20 2015 20:42
Cool
What do you think about the idea of splitting tolk into separate modules?
Peter Müller
@Munter
Oct 20 2015 20:47
That should certainly happen. The only question is which ones. I'm not sure I'm far enough in the process to know what the best abstractions are yet
Dave Jeffery
@davej
Oct 20 2015 20:50
Just the wrapper around accord that forwards 'my-file.scss' to the correct compiler, could be a great module by itself.
Gustav Nikolaj
@gustavnikolaj
Oct 20 2015 20:51
@Munter thanks for making me aware of the channel :-) I'll read up on it tomorrow. Good night!
Peter Müller
@Munter
Oct 20 2015 20:52
That wrapper will likely change when a concept of configuration enters the stage
Dave Jeffery
@davej
Oct 20 2015 20:55
I guess that's more stuff in the options object... but the abstraction is the same right?
Peter Müller
@Munter
Oct 20 2015 21:08
Possibly, yes
Peter Müller
@Munter
Oct 20 2015 23:13
@davej https://www.npmjs.com/package/jserror is out. Had to do a bunch of cleanup on csserror as well to make it work. Going to bed now and will look at htmlerror tomorrow