4 ms·

It's build tools. This is like complaining that Xcode is many gigabytes.

pistoriusp 6y ago
And, what about OS X, it takes a huge amount of space... and they install things I never use! It's almost as if these things run on code!
- cxr 6y ago
  These kinds of comments are against HN guidelines FYI.
  - pistoriusp 6y ago
    You're right, I was not in the best light last evening. My apologies to the community.
tedunangst 6y ago
I never had to install a new copy of xcode for every project.
- pistoriusp 6y ago
  So the problem is not the size, but that you want to have a single cache of all the npm modules?
johannes1234321 6y ago
Xcode is from a single vendor, whom I trust as much as I trust the operating system. With rails and npm I probably trust Rails and see them as license-wise ok, but due to version requirements I might get "newer" versions of a package, which hasn't been veted by Rails devs, might use different license, might do stuff I don't want it might add in even other new deps.
- isochronous 6y ago
  Then all you have to do is specify the specific version you want in your package.json, rather than a semver range, and you'll never get a version you haven't explicitly approved.
  - johannes1234321 6y ago
    Of each of the dependencies Rails installs.
    - schwartzworld 6y ago
      don't use an opinionated framework then?
rileytg 6y ago
I don't upload xcode.app to apple every time i submit an iOS app. I do npm install on every build on heroku.
- eropple 6y ago
  Then maybe don't use Heroku and use something that can work with a finished build? It's not complicated to set up a build container locally and ship only your final result to a service that can run it.
  - jspash 6y ago
    Just build locally and vendor the asset artefacts. That's how we did it in the "good old days". No containers in containers needed.
    - eropple 6y ago
      To be clear, you don't do "containers in containers", you build a container and you copy your assets from the other one. You then have a shippable artifact with all your dependencies, including your runtime, vendored into it. I'm not a k8s guy, but it's a lot nicer than a tarball.
  - deleted 6y ago
    [deleted]
  - rileytg 6y ago
    Heroku provides value in other ways for us. We run on a number of other solutions, most involve shipping a ~100mb image. This can be dramatically reduced in size with a slimmer base image, which we plan on doing eventually. In this case, heroku handles a lot of things we otherwise need to do ourselves: - DB + backups + DR - Network security - Network routing - SSL certs - Easy scaling of resources - Access control to operations (redeploy, restart etc) - Audits of operations etc We can do all these things, and under various compliance frameworks, outside of heroku; its just exhausting and expensive. This project we want to focus on the product so we opt for heroku as it was a few lines of bash we were all familiar with to get up and running nearly prod ready.

And, what about OS X, it takes a huge amount of space... and they install things I never use! It's almost as if these things run on code!

cxr 6y ago
These kinds of comments are against HN guidelines FYI.
- pistoriusp 6y ago
  You're right, I was not in the best light last evening. My apologies to the community.

tedunangst 6y ago

I never had to install a new copy of xcode for every project.

pistoriusp 6y ago
So the problem is not the size, but that you want to have a single cache of all the npm modules?

johannes1234321 6y ago

Xcode is from a single vendor, whom I trust as much as I trust the operating system. With rails and npm I probably trust Rails and see them as license-wise ok, but due to version requirements I might get "newer" versions of a package, which hasn't been veted by Rails devs, might use different license, might do stuff I don't want it might add in even other new deps.

isochronous 6y ago
Then all you have to do is specify the specific version you want in your package.json, rather than a semver range, and you'll never get a version you haven't explicitly approved.
- johannes1234321 6y ago
  Of each of the dependencies Rails installs.
  - schwartzworld 6y ago
    don't use an opinionated framework then?

rileytg 6y ago

I don't upload xcode.app to apple every time i submit an iOS app. I do npm install on every build on heroku.

eropple 6y ago
Then maybe don't use Heroku and use something that can work with a finished build? It's not complicated to set up a build container locally and ship only your final result to a service that can run it.
- jspash 6y ago
  Just build locally and vendor the asset artefacts. That's how we did it in the "good old days". No containers in containers needed.
  - eropple 6y ago
    To be clear, you don't do "containers in containers", you build a container and you copy your assets from the other one. You then have a shippable artifact with all your dependencies, including your runtime, vendored into it. I'm not a k8s guy, but it's a lot nicer than a tarball.
- deleted 6y ago
  [deleted]
- rileytg 6y ago
  Heroku provides value in other ways for us. We run on a number of other solutions, most involve shipping a ~100mb image. This can be dramatically reduced in size with a slimmer base image, which we plan on doing eventually. In this case, heroku handles a lot of things we otherwise need to do ourselves: - DB + backups + DR - Network security - Network routing - SSL certs - Easy scaling of resources - Access control to operations (redeploy, restart etc) - Audits of operations etc We can do all these things, and under various compliance frameworks, outside of heroku; its just exhausting and expensive. This project we want to focus on the product so we opt for heroku as it was a few lines of bash we were all familiar with to get up and running nearly prod ready.