The Makefile I use with JavaScript projects • Hacker News Board

Re: The Makefile I use with JavaScript projects

#261

Post by monocasa » Wed, Feb 28, 2018, 8:19 PM UTC

munificent wrote: post #94

monocasa wrote: post #73

Earlier quoted context omitted.

That was retconned. They didn't call it a 'transpiler' at the time.

"Transcompiler" was the older term for assembly -> assembly. I don't think it's too much of a stretch to shorten that to "transpiler". I think people hate the term because they associate it with JavaScript hipsters who have no sense of CS history and presume they've invented something new. The same as how you cringe when someone refers to the "#" character as "hashtag". But "transpiler" is a useful term. We're in a w…

> there are real workflow differences between working with a compiler that targets a low-level language versus a high-level one. Things like how you debug the output are very different.

Like what? When I've had to debug GCC, I just dumped out the GIMPLE et al.; what do you do differently with a 'transpiler'?

Re: The Makefile I use with JavaScript projects

#262

Post by tachyoff » Wed, Feb 28, 2018, 8:21 PM UTC

acemarke wrote: post #124

tachyoff wrote: post #81

Earlier quoted context omitted.

It's certainly better than the 200+ lines of JavaScript something like Webpack spits out when you statr a new project. I had to debug some of our project's build files and realized halfway through that my teammates didn't write this Webpack config monstrosity, Webpack generated it by /default/.

Webpack, by itself, doesn't generate configs, unless you're referring to the Webpack CLI tool. FWIW, Webpack 4 (which just went final a few days ago) now has "zero-config" defaults out of the box. You may want to give that a shot.

Eh, I tend towards “let’s not touch this if it works”. I’ve already had to upgrade from Webpack 1 to 2, and 2 to 3. If it ain’t broke, don’t fix it.

Re: The Makefile I use with JavaScript projects

#263

Post by dblotsky » Wed, Feb 28, 2018, 8:22 PM UTC

hungerstrike wrote: post #249

dblotsky wrote: post #240

Thank you. It's nice to know that I'm not alone in this dark, dark world. It's so depressing when people use arguments like "it's old", "it uses tabs", and "it's hard to learn". As described by one Peter Miller, "Make is an expert system". If a tool is the most powerful, standard, and expressive among its peers, its age or the fact that it uses tabs should be inconsequential. If anything, the fact that it's decades o…

The tools are not the same on every platform. That’s reason enough for me to not use it with my JavaScript projects. The bigger reason though is that it’s not very idiomatic for JavaScript projects to use Make. It sounds like the only reason that some people go out of their way to use it is because they actually don’t want to learn something.

> "The tools are not the same on every platform."

Any common examples?

> "It’s not very idiomatic for JavaScript projects to use Make."

While I agree that popularity is a factor in picking a tool, it shouldn't be a deciding factor. Going by popularity is precisely how we end up with a new Build System of the Year(TM) every few years. The fact that we've gone through 4 fairly prominent tools (Gulp, Grunt, Broccoli, Webpack), all of which contending to "fix" the previous, and none of which have proper DAG or incremental builds (which Make has had for decades) is damning evidence.

In other words, I think Make could be (and I wish it was) idiomatic for JS.

Re: The Makefile I use with JavaScript projects

#264

Post by LukeShu » Wed, Feb 28, 2018, 8:27 PM UTC

jerf wrote: post #104

jofer wrote: post #58

Earlier quoted context omitted.

Maybe I'm in the minority, but I've always found its syntax to be quite nice (though admittedly a departure from most modern languages). Then again, I find using JSON or not-quite-ruby to configure a build incredibly bizarre and confusing, so I guess I'm just set in my ways... In all seriousness, what's wrong with it? Significant tabs aren't great, but I feel like that's a relatively minor wart. The simple things are…

"In all seriousness, what's wrong with it?" 1. Claiming a rule makes a target, but then fails to make that target, ought to be a runtime fatal error in the makefile. I can hardly even guess at how much time this one change alone would have saved people. 2. String concatenation as the fundamental composition method is a cute hack for the 1970s... no sarcasm, it really is... but there's better known ways to make "templ…

(I'm making a separate comment from the INTERMEDIATE explanation)

I'm a big fan of Make, but appreciated your detailed criticism, and found myself nodding in agreement.

#3: I like to stick MAKEFLAGS += --no-builtin-rules in my Makefiles, for this reason. This, of course, has the downside that I can't take advantage of any of the builtin rules.

#7: There is a 3rd-party GNU Make debugger called Remake https://bashdb.sourceforge.net/remake/ https://sourceforge.net/projects/bashdb/files/remake/ It comes recommended by Paul Smith, the maintainer of GNU Make.

Re: The Makefile I use with JavaScript projects

#265

Post by JetSpiegel » Wed, Feb 28, 2018, 8:33 PM UTC

xaedes wrote: post #190

jayshua wrote: post #74

The concepts behind make are quite good, but the interface it provides is not decidedly not. It reminds me of Git in that respect. I'd think replacing the opaque symbols used everywhere with more descriptive words would be helpful. I don't suppose anyone knows if modern Make versions support alternatives to $@, $%, $?, etc. that can be read rather than memorized?

You _could_ do something like this: make -f- But for the sake of compatibility I wouldn't.

No need for ugly sed error-prone trickery.

Use on the Makefile:

    MAKE_TARGET := /some/path

And invoke

    $ make MAKE_TARGET=/other/path

Re: The Makefile I use with JavaScript projects

#266

Post by LukeShu » Wed, Feb 28, 2018, 8:36 PM UTC

jgh wrote: post #19

CMake is so nice compared to vanilla makefiles. I wonder if it can be used this way with Javascript.

As a distro packager, Autotools may be a mess, but debugging a package that won't build is fairly straight-forward. If the package uses CMake though, and there's a weird build issue, debugging that can be a nightmare! Everything is so opaque, with tons of implied complexity! CMake may be nice to write, but it's hell to debug.

Re: The Makefile I use with JavaScript projects

#267

Post by oso2k » Wed, Feb 28, 2018, 8:37 PM UTC

majewsky wrote: post #164

oso2k wrote: post #148

Earlier quoted context omitted.

Yeah make foo.c Should just work. No makefile needed.

No, `make foo`. You need to state the target, not the input.

You're correct.

   make foo

or

   make foo.o

Re: The Makefile I use with JavaScript projects

#268

Post by athenot » Wed, Feb 28, 2018, 8:38 PM UTC

bobbyi_settv wrote: post #192

athenot wrote: post #6

After going through a few build systems for Javascript, I realized they were all reinventing the wheel in one way or the other, and pulled out venerable Make from the closet. It turned out to be way more expressive and easy to read. One target to build (prod), another to run with fsevents doing auto-rebuild when a file is saved (instant gratification during dev), then a few targets for cleaup & housekeeping. All said…

The reason I don't like doing this is portability. Since the steps within the makefile are going to be run through a shell, it is going to behave differently on different systems. If your makefile fixes up a file using sed and your system has gnu sed, your makefile may fail on a system with BSD sed (e.g., a mac). If you rely on bash-isms, your makefile may not work on a debian system where it will be run with dash in…

True but I should specify that my targets do the job in 1 to 3 lines. No magic bash.

Also, I use javascript where it makes sense: I rely on Browserify to resolve the web of `require`d files.

Re: The Makefile I use with JavaScript projects

#269

Post by vanjoe » Wed, Feb 28, 2018, 8:41 PM UTC

sneak wrote: post #38

rectang wrote: post #23

Make's interface is horrible. Significant tabs. Syntax which relies on bizarre punctuation... If only whoever authored Make 40 years ago had had the design acumen of a Ken Thompson or a Dennis Ritchie! We're stuck with Make because of network effects. I wish that it could just become "lost" forever and a different dependency-based-programming build tool could replace it... but that's just wishful thinking. The pace o…

FWIW $ $@ is target, because @ looks sort of like a bullseye. significant tabs are gross, yes, but this is a one-time edit to your vimrc then you can forget about it forever. it’s also installed everywhere and has minimal dependencies. it could be a lot worse. (see also: m4, autoconf, sendmail.cf)

But how do you remember when to use $^ and $<

Re: The Makefile I use with JavaScript projects

#270

Post by drablyechoes » Wed, Feb 28, 2018, 8:49 PM UTC

I have used Makefiles for a lot of little things over the years. One of the latest things I have found it useful for is automating deployment of websites via Jenkins jobs.

It is a lot easier and more manageable if your Jenkins job is set up to just run a series of generic Make commands for a project, where any specific steps for a particular project are defined in the Makefile.

This way I do not need to know or care about how any particular project or site is built when configuring the job to deploy it. The Makefile takes care of all that.