emberjs.tgz appears to be stale

[ohsnapitscolin]

Hey! We're running into an issue with https://codon-buildpacks.s3.amazonaws.com/buildpacks/heroku/emberjs.tgz and Node 12.18.3.

When building, we get the following error:

-----> emberjs app detected
-----> Setting NPM_CONFIG_PRODUCTION to false to install ember-cli toolchain
-----> Fetching buildpack heroku/nodejs-v98
-----> Node.js detected
-----> Creating runtime environment

       NPM_CONFIG_LOGLEVEL=error
       NPM_CONFIG_PRODUCTION=false
       NODE_ENV=production
       NODE_MODULES_CACHE=true
       NODE_VERBOSE=false
-----> Installing binaries
       engines.node (package.json):  12
       engines.npm (package.json):   unspecified (use default)

       Resolving node version 12 via semver.io...
       Downloading and installing node 12.18.3...
       Unable to download node 12.18.3; does it exist?
-----> Build failed

We raised an issue with heroku-buildpack-nodejs, but through that process found that we appear to be building with an out of date version (v98) of the buildpack.

A change was made to this repo back in 2019 to unpin version 98: https://github.com/heroku/heroku-buildpack-emberjs/commit/8760c52ddd04941ae3b1c6af750199414cb8fd0e, but https://codon-buildpacks.s3.amazonaws.com/buildpacks/heroku/emberjs.tgz doesn't seem to reflect that change.

Downloading and extracting the bin and vendor directories, it looks like they were last modified in May of 2017. Is there any chance https://codon-buildpacks.s3.amazonaws.com/buildpacks/heroku/emberjs.tgz could be made up to date with the most recent changes?

[jtgeibel]

I was able to get rake compile working in #62. Then I built on Ubuntu 16.04 (to be compatible with the heroku-16 stack) and packaged a custom *.tgz (mirroring the file layout of the upstream release).

emberjs.tar.gz - Note that I've uploaded this as a .tar.gz so that GH would accept it, but to be compatible with heroku-buildpack-multi the extension must be .tgz.

[rajveerappan]

@jtgeibel I similarly got it building (using docker-compose run compile) and used the updated binary with Heroku but I noticed that it was still Fetching buildpack heroku/nodejs-v98 when running CI tests. I saw that nodejs-v98 is still used in two places: https://github.com/heroku/heroku-buildpack-emberjs/blob/77ef61476dc73f1baa5325ef232822bdb9f2ad9d/buildpack/mrblib/buildpack/commands/test_compile.rb#L20 https://github.com/heroku/heroku-buildpack-emberjs/blob/77ef61476dc73f1baa5325ef232822bdb9f2ad9d/buildpack/mrblib/buildpack/commands/test.rb#L19

and after unpinning in those two locations my custom build started correctly fetching the latest nodejs buildpack.

Wondering if you saw a similar issue using your custom embjers.tar.gz package with Heroku? Basically I'm not sure if it's sufficient to just publish a new version from master to https://codon-buildpacks.s3.amazonaws.com/buildpacks/heroku/emberjs.tgz or whether the two files I mentioned need to be fixed first.

[jtgeibel]

@rajveerappan I'm sure you're right, it looks like those lines should be updated as well. Since that's in the tests I don't think it should impact the file I built, but I agree the version should be unpinned there too.

[jtgeibel]

Oh, I have noticed that it appears the ember application is being built twice with the package I built. I'm guessing that the nodejs buildpack now runs npm run build, and then this buildpack runs it again. I haven't looked into this at all.

[ohsnapitscolin]

@jtgeibel have you been able to successfully build on Heroku with the custom built package linked in https://github.com/heroku/heroku-buildpack-emberjs/issues/61#issuecomment-664744112? We've tried downloading, compressing and hosting it but running into an App not compatible with buildpack: error.

[jtgeibel]

Hey @ohsnapitscolin, yes I've use that custom built package to build an application on Heroku. To clarify, there should be no need to compress the file, just to rename it to emberjs.tgz. Maybe the file you're hosting was compressed a 2nd time. The other thing I would check is if the web server is sending content-encoding: gzip then maybe the client (downloading the buildpack within the build environment) is decompressing when some later part of the script expects compressed input.

[ohsnapitscolin]

Thanks @jtgeibel! Not sure if I messed something up during the extracting and re-compressing process, but just simply renaming got it working for me! For anyone else with the issue, downloading emberjs.tar.gz, renaming it to emberjs.tgz and hosting the file yourself should resolve the issue.

It's also worth noting the Heroku seems to now support Node 12.18.3, but probably still best to get off heroku/nodejs-v98.

[imanuelgittens]

@jtgeibel this helped me a lot! I'm still hopeful that the official buildpack will be updated though.

[lancedikson]

Running into the same issue. Fixing node version to 12.18.2 fixed the problem for us, but it would be nice not to be blocked by that 🙂

[andrewcallahan]

Can second that setting node to 12.18.2 works for me! Great temporary solution that finally allows new builds!!

[edmorley]

@hone I came across this issue recently (see context in W-7981024) and thought I'd try to quickly push out a new release to resolve the issues here.

I tried using rake publish from the root of this repo, however the Docker build of the compiled binary failed with:

...
Cloning into '/home/mruby/code/mruby/build/mrbgems/mruby-yaml'...
remote: Enumerating objects: 8, done.
remote: Counting objects: 100% (8/8), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 8 (delta 0), reused 6 (delta 0), pack-reused 0
Unpacking objects: 100% (8/8), done.
Checking connectivity... done.
build: [exec] curl http://pyyaml.org/download/libyaml/yaml-0.1.6.tar.gz | tar -xzv
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   162  100   162    0     0   1142      0 --:--:-- --:--:-- --:--:--  1148

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
rake aborted!
curl http://pyyaml.org/download/libyaml/yaml-0.1.6.tar.gz | tar -xzv failed
/home/mruby/code/mruby/build/mrbgems/mruby-yaml/mrbgem.rake:19:in `block in run_command'
/home/mruby/code/mruby/build/mrbgems/mruby-yaml/mrbgem.rake:17:in `run_command'
/home/mruby/code/mruby/build/mrbgems/mruby-yaml/mrbgem.rake:28:in `block (2 levels) in <top (required)>'
/home/mruby/code/mruby/build/mrbgems/mruby-yaml/mrbgem.rake:26:in `chdir'
/home/mruby/code/mruby/build/mrbgems/mruby-yaml/mrbgem.rake:26:in `block in <top (required)>'
/home/mruby/code/mruby/tasks/mrbgem_spec.rake:80:in `instance_eval'
/home/mruby/code/mruby/tasks/mrbgem_spec.rake:80:in `setup'
/home/mruby/code/mruby/tasks/mrbgem_spec.rake:327:in `generate_gem_table'
/home/mruby/code/mruby/mrbgems/mruby-test/mrbgem.rake:35:in `block in <top (required)>'
/home/mruby/code/mruby/tasks/mrbgem_spec.rake:80:in `instance_eval'
/home/mruby/code/mruby/tasks/mrbgem_spec.rake:80:in `setup'
/home/mruby/code/mruby/tasks/ruby_ext.rake:41:in `block in to_proc'
/home/mruby/code/mruby/tasks/mrbgem_spec.rake:290:in `each'
/home/mruby/code/mruby/tasks/mrbgem_spec.rake:290:in `each'
/home/mruby/code/mruby/tasks/mrbgems.rake:4:in `block in <top (required)>'
/home/mruby/code/mruby/tasks/mruby_build.rake:13:in `instance_eval'
/home/mruby/code/mruby/tasks/mruby_build.rake:13:in `block in each_target'
/home/mruby/code/mruby/tasks/mruby_build.rake:12:in `each'
/home/mruby/code/mruby/tasks/mruby_build.rake:12:in `each_target'
/home/mruby/code/mruby/tasks/mrbgems.rake:1:in `<top (required)>'
/home/mruby/code/mruby/Rakefile:26:in `load'
/home/mruby/code/mruby/Rakefile:26:in `<top (required)>'
/home/mruby/code/rakefile:22:in `load'
/home/mruby/code/rakefile:22:in `<top (required)>'
(See full trace by running task with --trace)
rake aborted!
Command failed with status (1): [docker-compose run compile...]

The curl/untar of http://pyyaml.org/download/libyaml/yaml-0.1.6.tar.gz is failing since it now returns an HTTP 301 to the HTTPS URL.

It looks like upstream mruby-yaml has fixed this: https://github.com/hone/mruby-yaml/compare/master...mrbgems:master

@hone would you mind updating https://github.com/hone/mruby-yaml to s/http/https/ for that URL (or else pulling in the changes from upstream)? I realise this buildpack is not actively maintained, but publishing a new release would really help out the users above (see also the support ticket list in W-7981024). Thanks :-)

[camerondubas]

With the release of Node 12.18.4 which includes two security patches, getting this buildpack updated has become even more important.

Is there any progress being made here? I'm happy to help if I can.

[musaffa]

It's a shame that an official buildpack of Heroku has been left unmaintained for such a long time.

[cloke]

FWIW pinning to node 12.18.2 also worked for me and then today deploys started failing again. Pinning everything to the last known working version fixed it for me: "engines": { "node": "12.18.2", "npm": "6.14.5", "yarn": "1.22.5" },

[joekarl]

I'm following up on this thread as this buildpack really should get updated as it's un-useable with more recent versions of node (in particular 14+).

A workaround (thanks @James1x0) had was to unpin the node buildpack version (this is done in master currently), build the buildpack binary, and then commit said binary back into the repo at vendor/buildpack. you can then use the .git URL of your repo for specifying the buildpack (in either .buildpacks or buildpacks:set).

This would allow #63 (point to the .git URL of this repo) to be functional even as it's binary based instead of repo based.

All that said, probably a better alternative would be to add a release to this repository that contained the built buildpack binary as a tar.gz and then set the instructions to point to the latest release on github.

I hesitate to recommend forking, building the binary in the fork, and pointing your application at that fork, but it is a work around if you really need this to work today.

[musaffa]

I'm using a fork of this repository: https://github.com/James1x0/heroku-buildpack-emberjs

$ heroku buildpacks:set https://buildpack-registry.s3.amazonaws.com/buildpacks/aedev/emberjs.tgz

It provides the updated binary. You can use the latest nodes with this buildpack.

Warning: The fork is a third party buildpack. Use it with your own risk.

[James1x0]

I'm using a fork of this repository: https://github.com/James1x0/heroku-buildpack-emberjs

$ heroku buildpacks:set https://github.com/James1x0/heroku-buildpack-emberjs

It provides the updated binary. You can use the latest nodes with this buildpack.

Warning: The fork is a third party buildpack. Use it with your own risk.

Hi there - we use this fork in some prod apps and try and update it when it breaks. Happy to review any PRs if someone wants to help out! It also has a binary on the official buildpack registry, so make sure and use that instead of the GitHub link unless you like living on the edge :)

[cloke]

I noticed that the "About" now shows "This buildpack is deprecated! Please use the official Node.js buildpack combined with the static buildpack instead." If anyone has an example of this method that would be great as it appears this build pack won't be receiving updates.

[lancedikson]

@cloke, we don't use fastboot, thus it makes the configuration a little bit easier. Here is what works for us, maybe will be applicable for you as well:

1. Make sure you've added the following buildpacks to the app:

   heroku/nodejs
   https://github.com/heroku/heroku-buildpack-static.git

   Also, pay attention to the order: during building they should appear exactly in the mentioned order.

2. Add a static.json that points out to the dist dir:

   {  
   "root": "dist/",
   "routes": {
   "/**": "index.html"
   }
   }

3. Add build command to the scripts section in package.json:

   "scripts": {    
     "build": "ember build --environment=production",
   ....

That's all. Hope this helps! 🙌🏻

[Subtletree]

@lancedikson Awsome! Working for me too and feels damn good to get rid of heroku-buildpack-emberjs