Yeah I’ve not had these issues on my linux desktops at home, though my projects there are quite a bit smaller and less complex then the one at work. So the one at work, where I have all the issue, is both far far larger and it is on Windows, either one could be why brunch is painful there, either one is bad for having brunch as a default in phoenix though.
Honestly I’d say default should be the npm way, with a --brunch to enable brunch, --webpack to enable webpack, etc… The default way should be the most simple and reliable, and brunch is definitely not reliable on all platforms that Phoenix supports. And debugging into webpack/gulp issues is remarkably painful (that is something that brunch does better than them).
I think the node world is painful no matter what approach you take and there’s no silver bullet. My main concern with the proposed approach is you end up accidentally rebuilding brunch, but worse, with a hodgepodge of dependent scripts. I think it’s a great choice if it’s working well for you, but I remain unconvinced that it’s the best approach for the majority of users.
I am guessing there is a fairly low probability of that change so having a convenient package might be the second best option . and having it merged into phoenx so --webpack to enable webpack --npm to just use npm --gulp to use gulp would be nice.
Hear hear, that is why I’m trying to remove as much of it as I can.
It is a way that many npm projects do things I’ve been noticing today. It is not that you are rebuilding brunch, rather you are just calling the main interfaces that things like brunch try to hide from here (thus causing the plugins to be out of date, missing features, etc… etc…) from a shell-like interface (which can include calling a custom script via node myScript if you want, but I’ve not actually had to do that surprisingly). Each npm shell entry in packages.json is just a single shell command each, with it documented that &&, <, >, and | will be supported on all shells on all platforms that the scripts run on, so keeping to that, using things like rimraf (like my clean command is "clean": "rimraf priv/static/*",) instead of rm -rf for multi-platform, then you are good and it works and you can easily tear things apart or run commands yourself to see exactly what they do. No need for a multitude of plugins in whateverBuildSystem that may or may not be up to date (many in brunch are not), may or may not support the features you may need from the underlying library the plugin uses (many of my brunch plugins had not, hence why I’ve had to rewrite a few of them), when all is exposed fine through the normal node interface. Like here was my elm plugin section in brunch-config.js:
elmBrunch: {
elmFolder: '.',
mainModules: [
'web/elm/MessengerApp.elm',
'web/elm/NotificationApp.elm'
],
// If these next two are specified, all mainModules will be compiled to a single file (optional and merged with outputFolder)
outputFolder: 'web/static/js',
outputFile: 'elm.js',
makeParameters: ['--warn', '--yes']
},
The npm version is:
"build:elm.js": "elm make web/elm/*.elm --output web/static/js/elm.js --warn --yes"
Elm cannot output to stdout, but nor can the brunch plugin or anything, and I was just converting the brunch style. I’m thinking of changing the output style a bit.
I still find it funny that the elm make command takes over 40 seconds to compile (find web/elm/ -iname '*.elm' | wc -l) 31 files, yet bsb.exe (bucklescripts compiler) takes < 1.5s to build (find web/bucklescript -iname '*.ml' | wc -l) 55 files and elm is (via du) is 190K (and compiles to 891K javascript, ~730K after minimization) and bucklescripts is 908k (I’ve built a very large library, compiles to 1.1megs javascript, ~280K after minimization, BS uses the javascript module system along with a design that is able to be optimized well, also it puts in a lot of comments, where elm output has no comments)).
I know, I’m just trying to spur conversation.
Currently it is mostly just ‘it should be easy’ but there has been no examples of talk on ‘how’ brunch/webpack is easier than npm, and currently I’m finding it to be the opposite, as well as faster.
If we had replaced the assets engine every time someone found an allegedly new/better/faster solution, we would be on our 26th interaction with possibly no or little noticeable improvement. If brunch is not for you, then go and replace it by something else. We chose brunch for everyone who doesn’t want to care or cares very little about the js build tool.
This is the second or third time this week we are on the same discussion. It does not help. We have limited time and I would prefer to use that time in not rehashing topics that have already been debated in such short time span.
Just to back this claim, at my company we care little about js build tool, and brunch works perfectly for us. It provides a low ceremony out of the box experience that does the job gets out of the way. So I’m personally really happy with that. My understanding is that more demanding users can easily replace brunch with anything else, so I’m not sure why this topic is raised so frequently?
To be a bit less negative and contribute more positively to the discussion: what would help is to document those steps in articles, blog posts and get people trying it out. The article someone shared a couple days ago about Webpack with Phoenix was great (and it was the first time I could understand how to configure Webpack).
I don’t think the issue is with demanding users , while not being an advocate of change I think the frequency of issue being raised still might be a good indicator that there might be a need for some solution.
That is what I’ve been curious about, it builds very poorly, no support of other processes, webcomponents, image processing (spritesheet generation, minimizing/optimizing), etc… It essentially has support for javascript with babel, css (and for things like scss you have to choose to either output css or js, cannot have both), and an unprocessed asset path that is copied verbatim (no ability to have something like svg icons in node_modules somewhere auto-update, svg-minimize, and output an output svg file + css file). The big issue however is how it randomly and often misses files as the project gets bigger when running on Windows (which is what started all of this), and that is even with just javascript.
Do feel free to ignore these though, it does work fine on at least linux for the simple purpose it is included for if not a bit verbosely.
It breaks often, and can be replaced with a single line (or two if you want watch support) in the npm package.json file, which will not break. It provides a bad user experience that I’ve had to walk a few people through.
Heh, I actually used that article in my webpack testing (older than a few days? Or a different one), but it ends up being even more verbose than gulp/brunch in its setup and configuration. I am thinking of putting up something that documents it, would not be hard (need to make a new project, my structure is so changed up because certain javascript libraries are stupid and need specific things in specific places to build…).
I’ve not noticed others so it might be my fault? Sorry for the bugging. ^.^
But yeah, translating brunch to npm scripts should be easy, will try to find the time this weekend to document it up (my work is forcing me to stop working from home on weekends and instead use my free time as free time because of new laws going into effect in the USA, blehg, wasted time is what it is…).
Not necessarily - often it’s just a case that people want to see their favorite tool supported, regardless of how appropriate that tool may be. In this particular case it just happened that an approach using smaller building blocks ended up being more effective under the circumstances.
The issue is that such “convenience” comes with an opportunity cost - a cost that users of the Phoenix framework shouldn’t underestimate nor take for granted. Supporting only one single approach/tool is ultimately more effective; support of the other tools in the wild should really be left to the “evangelists” of those tools. How serious can you take anyone who would reject Phoenix because brunch is its default asset management tool?
[quote=“chrismccord, post:13, topic:2454”]
My main concern with the proposed approach is you end up accidentally rebuilding brunch, but worse, with a hodgepodge of dependent scripts.[/quote]
I’m past the “remove brunch from Phoenix” discussion - there is no need to change it, especially given that it is so easy to replace if and when the need arises.
However in general this particular argument seems to favor monolithic tools over pipelined tools. I personally find the whole “batteries included” mindset a bit oversold, a holdover from commercial products where companies are trying to compete on the sheer number of features to the point that you are accepting a fair bit of bloat. Given that OSS is notorious for not settling on a standard, focusing on (quick to learn) single-responsibility tools that combine well with one another seems to be a reasonable approach, especially when you should be able to replace any part that is no longer pulling its weight (rather than replacing your entire build process because your monolithic tool is starting to show a key weakness in one particular area). Yes, it is absolutely possible to create “a hodgepodge of dependent scripts” but ultimately no tool (or set of tools) is a substitute for thinking.
I think it is clear that the utility of npm scripts is often overlooked and I guess it is my overly idealistic hope that having people focus on “(quick to learn) single-responsibility tools that combine well with one another” could be a way to further increase the quality of tooling - hopefully to make the node/JS world just a little less painful.
. and having it merged into phoenx so --webpack to enable webpack --npm to just use npm --gulp to use gulp would be nice.
