Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Makefile I use with JavaScript projects

olioapps.com

Post reply on HN
Print view View original

391–400 of 525 posts

Re: The Makefile I use with JavaScript projects

#391

Post by codazoda »

kraig911 wrote: post #370

A lot of good arguments about using and not using make. Count me in the not using make camp. IMO it's just simply overkill. JS work nowadays is so modular if we were talking about configuring a monolith service at build time... sure yeah. Meanwhile I just wanna make this div purple.

I presume you're running simple small js files. This post is about larger projects that need to transpile newer js code down to browser compatible code, combine multiple files into 2 or 3 http requests, and pack every possible byte out of the js resources we end up sending to clients.

Re: The Makefile I use with JavaScript projects

#392

Post by jtolmar »

gdwatson wrote: post #248
reificator wrote: post #239

Earlier quoted context omitted.

Human beings who name things are going to use spaces. That spaces were used as delimiters for computers is somewhere between unfortunate and a colossal mistake. But to use that as evidence of why spaces should not be supported in filenames is putting the cart before the horse. The goal of software is not to perpetuate whatever mistakes have been made in the past. It's to solve problems for human beings. And human bei…

On the command line, using spaces to delimit words is also quite natural; that's why they get used as a delimiter: mv old-file new-file Spaces separate the verb, the direct object, and the indirect object. Using commas or colons instead would painfully artificial. So the question is whether you will favor naturalness on the command line or in the GUI. It's no surprise that a Unix build tool favors the command line.

What if your file system didn't distinguish between underscores and spaces, your GUI displayed them as spaces, and your command line displayed underscores?

Then this problem goes away entirely and you instead have the problem of not being allowed to have "this_file" and "this file" in the same directory. A problem which probably doesn't matter.

Re: The Makefile I use with JavaScript projects

#393

Post by voltagex_ »

emmelaich wrote: post #375
bpicolo wrote: post #153

Earlier quoted context omitted.

https://stackoverflow.com/a/29787362 > remotely defensible Feel free to write your own make superset that supports spaces. It's an irrelevant factor to the usability of make as a whole.

It's something that almost everyone trips over. Multiple times. Actually writing a preprocessor for Make sounds like a pretty good idea.

ninja, cmake, premake.

Re: The Makefile I use with JavaScript projects

#394

Post by MaulingMonkey »

Cyph0n wrote: post #128
MaulingMonkey wrote: post #108

Earlier quoted context omitted.

> Because, like many other things in programming, you'll end up with a half-baked and buggy implementation of make anyways. I'd argue that make is a half-baked and buggy implementation of make - so that's not really a drawback so much as the status quo. E.g. I have scripts that exist mainly to carefully select the "correct" version of make for a given project to deal with path normalization and bintools selection iss…

> path normalization and bintools selection issues on windows make was never intended to be a cross-platform tool. If you face problems using it on Windows, then that's on you.

All the more reason to use a regular scripting language for building, then, since there are several that are plenty cross-platform.

Re: The Makefile I use with JavaScript projects

#395

Post by MaulingMonkey »

falcolas wrote: post #132
MaulingMonkey wrote: post #108

Earlier quoted context omitted.

> Because, like many other things in programming, you'll end up with a half-baked and buggy implementation of make anyways. I'd argue that make is a half-baked and buggy implementation of make - so that's not really a drawback so much as the status quo. E.g. I have scripts that exist mainly to carefully select the "correct" version of make for a given project to deal with path normalization and bintools selection iss…

I'd argue that there are some major concerns with the makefiles if they require the use of 3 different versions of make to get it all working - a situation I've never personally seen before. I'd suggest prioritizing fixing that before attempting tracking down the cause of other issues. As it stands, there are too many points of interaction to attribute any bugs to any one program. That said, Windows has never been a…

> I'd suggest prioritizing fixing that

I've already had one upstream patch rejected on account of the additional complexity fixing it introduces, and would rather not indefinitely support my own fork of other people's build setups.

Or if I am going to indefinitely support my own fork, I might as well rewrite the build config to properly integrate with the rest of whatever build system I happen to be using - at least then I'll get unified build/compilation options etc.

Re: The Makefile I use with JavaScript projects

#396

Post by fuball63 »

ethagnawl wrote: post #33
fuball63 wrote: post #22

We use make for standardizing the way docker containers are built, pushed, tested, and run (debug and production modes). I even prefer it to docker-compose at this point, because it is more programmable.

If you're able, I'd be very interested in seeing some examples.

  SHELL=/bin/bash
  VERSION=1.0
  
  build: clean
  	docker build -t webservice:$(VERSION).$$(date +"%y-%m-%d") .
  
  shell:
  	docker run -it -v $$(pwd)/src:/opt/app \
  	-p 8888:8888 \
  	--name webservice \
  	-e SECRET1=$$SECRET1 \
  	-e SECRET2=$$SECRET2 \
  	webservice:$(VERSION).$$(date +"%y-%m-%d") \
  	/bin/bash
  
  run:
  	docker run -it  \
  	-p 8888:8888 \
  	--name webservice \
  	-e SECRET1=$$SECRET1 \
  	-e SECRET2=$$SECRET2 \
  	webservice:$(VERSION).$$(date +"%y-%m-%d")
  
  tag:
  	docker tag webservice:$(VERSION).$$(date +"%y-%m-%d") webservice:latest
  
  push: tag
  	docker push webservice:$(VERSION).$$(date +"%y-%m-%d")
  	docker push webservice:latest
  
  clean:
  	-docker kill webservice
  	-docker rm --force webservice
  
  test:
  	docker run -it \
  	--name webservice \
  	webservice:$(VERSION).$$(date +"%y-%m-%d") \
  	python3 tests.py
Couple of notes:

- I do major.minor.yy-mm-dd versioning, so this handles that automatically

- shell is for dropping you into a prompt with your present directory mapped to the working directory. I find this super helpful for debugging and testing containers

- run is for testing your CMD and entrypoint scripts

Re: The Makefile I use with JavaScript projects

#397

Post by fuball63 »

drdaeman wrote: post #117
fuball63 wrote: post #22

We use make for standardizing the way docker containers are built, pushed, tested, and run (debug and production modes). I even prefer it to docker-compose at this point, because it is more programmable.

Do you handle dependencies (images, networks, volumes), and if you do - how? I'm of an opinion that Makefiles with Docker are mostly a fancy way to write `case "$1" in build) ... run) ... esac` except that one needs to have make(1) installed to run them (in my experience, Bourne shell is much more commonly available than any make variant)

I've generally had to only do this for more-or-less stand alone webservices, but there's nothing preventing making extra targets for setting up networks. To date, I'm still using docker compose for that.

I started doing makefiles as a reaction to having a bunch of bash scripts cluttering up my directory. More or less just a collection of useful commands. But as I continue to do this, I find it encourages making consistent build routines/versioning. Also, being able to set up dependencies ( like "run relies on build") can also be helpful. Finally, variable substitution is useful for versioning.

I think what makes makefiles great are you can do as much or as little as you want with them. I put an example of a common one in another reply.

Re: The Makefile I use with JavaScript projects

#398

Post by fuball63 »

mauvehaus wrote: post #93
ethagnawl wrote: post #33

Earlier quoted context omitted.

If you're able, I'd be very interested in seeing some examples.

Not the OP, doing a bit less that it sounds like the OP is doing, but we built out a relatively handy make-based build system for building a set of images in correct dependency order. Another member of the team subsequently taught make about the reverse dependencies so that you can split jobs across Travis nodes by the top-ish level image they depend on. My favorite addition was the ability to generate a dependency g…

That's pretty interesting about Travis. Make is great because you can do as much or as little with it as you want, but it generally always improves organization.

Re: The Makefile I use with JavaScript projects

#399

Post by Spivak »

lisper wrote: post #387
ori_b wrote: post #247

Earlier quoted context omitted.

On plan 9, you'd do something like: ctlfd = open("/mnt/sql/ctl", OREAD|OWRITE); write(fd, "your query"); read(fd, resultpath); resultfd = open(resultpath, OREAD); read(fd, result); close(resultfd); This is similar to the patterns used to open network connections or create new windows.

And how would you use that in a makefile?

Something like this would be ideal.

    /mnt/sql/myjoin:
      echo "" > /mnt/sql/myjoin
It's just representing writing and reading a database as file operations, they map pretty cleanly. Keep in mind that Plan 9 has per process views of the namespace so you don't have to worry about other processes messing up your /mnt/sql.
Post reply on HN