No such file or directory @ rb_sysopen - /Users/collins/git/<app>/tmp/ember-cli-<uuid>/apps/frontend/index.html

[patcoll]

I am getting this error on startup in development environment, in cases where the first request to Rails is not one for my mounted Ember app.

Errno::ENOENT in Assets#index
No such file or directory @ rb_sysopen - /Users/collins/git/<app>/tmp/ember-cli-<uuid>/apps/frontend/index.html

When this happens I must restart my local development server and make sure the first request is to /, where my app is mounted, so it can trigger ember-cli-rails.

I have a series of endpoints mounted under /api separate from any Ember app, so I've been using those endpoints to test.

Steps I take to reproduce:

• start up my local development server with latest ember-cli-rails version 0.5.8
• don't request anything in a web browser
• run curl -s http://localhost:8123/api/assets
• request http://localhost:8123/ in a web browser
• get the above error

[seanpdoyle]

@patcoll thanks for bringing this to our attention!

Would you mind trying out #327, following these instructions?

[patcoll]

Is building necessary if I've performed assets:precompile? Is it a no-op in that case?

[patcoll]

Yep, I found the before_action build workaround in another ticket, but it's causing #332, which I'm working around for now with the code I pasted there. I hope this helps someone. Thanks again for all your help.

[seanpdoyle]

@patcoll currently, it's only a no-op outside of development and test (which assumes that you've assets:precompile'd)

ember-cli-rails/lib/ember_cli/app.rb

Lines 42 to 48 in b54abab

	if development?
	build_and_watch
	elsif test?
	compile
	end
	@build.wait!

[patcoll]

I still get this error in some cases if I come back to my computer after a bit, with my development server running, still using the build workaround documented below. In that case I must restart my dev server, and as long as I hit the mounted Ember app first, all is well. For a while.

The build workaround I mentioned above is this (using a custom controller with mount_ember_app):

class AssetsController < ApplicationController
  def build_frontend
    EmberCli[:frontend].build
  end

  def run_build?
    Rails.env.development? || (Rails.env.test? && ENV['CI'].blank?)
  end

  def index
    build_frontend if run_build?
  end
end

[seanpdoyle]

@patcoll are you using puma or unicorn?

https://github.com/thoughtbot/ember-cli-rails#serving-from-multi-process-servers-in-development

[patcoll]

Yep I've been down that road and solved that already. Using puma with 1 worker process and 16 threads. Equivalent of puma --workers 1 --threads 16:16

[seanpdoyle]

@patcoll can you still reproduce the erratic error with MAX_THREADS=1?

[patcoll]

I'll try that setting this week and see if it happens again!

[patcoll]

@seanpdoyle If I use MAX_THREADS=1 I can't reproduce using the original steps I documented in the initial bug report.

I'll continue to monitor this week to see if the intermittent version of this error re-occurs.

[edit: mark code in markdown]

[seanpdoyle]

@patcoll would you mind trying out:

• https://github.com/thoughtbot/ember-cli-rails/tree/remove-sprockets for ember-cli-rails gem
• https://github.com/rondale-sc/ember-cli-rails-addon/tree/remove-sprockets for ember-cli-rails-addon

Each of those branches has up-to-date README's.

[patcoll]

Using those seem to work -- all my smoke tests pass as before, and my quick manual check was good too.

The paths changed for some assets. The paths changed from having a prefix of /assets/frontend/' to having no prefix at all, so my vendor CSS path went from /assets/frontend/assets/vendor.css to just assets/vendor.css.

Some questions:

• I realize this is cleaner, but I worry that I'm just in the "happy path" with only one Ember app mounted. What happens when I have multiple?
• If my app is mounted at /, which it is now, shouldn't that be the prefix that ends up in the HTML? So the vendor CSS would be /assets/vendor.css... (and for an app mounted at /admin, the path would get rewritten to be /admin/assets/vendor.css)

Now this was not a problem for CSS and JS, since ember-cli-rails seems to have the power to transform the CSS and JS paths in the HTML path to be the right ones, but I copy fonts manually in the Ember compilation process too and I had to change that path. No biggie for me, since it was in a SCSS variable, but it's not ideal. The ember-cli-rails-addon is a true Ember addon, so I wonder if there is any way to provide a CSS or SCSS helper or transformation that could accept the name of the Ember app you've mounted and provide a transformed URL, similar to the Rails Sprockets helpers like font-url, etc. Could be neat to have a helper in the CSS that reads frontend-url('fonts/glyphicons-halflings-regular.woff'); or similar...

[seanpdoyle]

@patcoll checkout the second commit of https://github.com/seanpdoyle/ember-cli-rails-heroku-example/tree/remove-sprockets

It adds support for a second Ember app mounted elsewhere

[patcoll]

I like the coincidence that the paths line up with your sample app when developing locally for assets/vendor.css and admin/assets/vendor.css but I wonder if it's better to have those paths be explicitly absolute, like I mentioned above, since we already know where the apps are mounted. This would restore previous similar behavior.

[seanpdoyle]

This would restore previous similar behavior.

What is the difference in behavior between two URLs that are different, but are both served properly?

[patcoll]

The behavior I'm looking for can be accomplished by simply adding a leading slash to paths in the index.html file.

I changed:

<link rel="stylesheet" href="assets/vendor.css">
<link rel="stylesheet" href="assets/frontend.css">
<!-- ... -->
<script src="assets/vendor.js"></script>
<script src="assets/frontend.js"></script>

To this:

<link rel="stylesheet" href="/assets/vendor.css">
<link rel="stylesheet" href="/assets/frontend.css">
<!-- ... -->
<script src="/assets/vendor.js"></script>
<script src="/assets/frontend.js"></script>

Similarly for my new admin app, I prefix the paths with /admin.

Then I can use the same exact value for the fingerprint.prefix option in production. Works great.

[patcoll]

I still rarely (intermittently, again) get a similar error to the original one reported here, while using the remove-sprockets stuff. I put it in a gist here: https://gist.github.com/patcoll/c3aa88e69a191fbb7721 (easiest solution is to download ZIP and drag into a browser).

I need a custom controller, so the current workaround that seems to work is this:

class AssetsController < EmberCli::EmberController
  def index
    EmberCli.build(:frontend)
  end
end

Again, with PUMA and 1 worker and 1 thread locally.

Inheriting from EmberCli::EmberController makes it so much easier to keep up with updates that get made there :)

[seanpdoyle]

@patcoll remove-sprockets was merged into master.

Also, 2b26309 was merged as well, which removes the burden of invoking EmberCli.build from the consumer.

Also, if you have a single EmberCLI application, and the only thing you're altering is the view, you can avoid routing to your custom controller and override the view.

[seanpdoyle]

The behavior I'm looking for can be accomplished by simply adding a leading slash to paths in the index.html file.

Yes, I understood the outcome that you desired, but what is the difference in behavior? URLs both with and without the leading slash are served properly. Supporting the former would require additional work, supporting the latter works out of the box.

EmberCLI's generated index.html uses relative paths, which refer to assets that Rails knows how to serve.

This gem has no business altering asset URLs in that generated index.html.

[patcoll]

FWIW, even with ember-cli-rails 2b26309 and the latest workaround documented above, I am still getting the error linked to in the gist. Specifically: EmberCLI failed to generate an index.html file. Also, using rondale-sc/ember-cli-rails-addon@cadb98a of ember-cli-rails-addon

[seanpdoyle]

Hmm.

Are you sure you're on that commit of the addon? NPM can be very finnicky.

I'm not sure how to proceed with this.

Would you feel comfortable granting me temporary access to the problem repository?

[patcoll]

Behavior with relative asset URLs in well-behaved browsers seems identical. I fear incompatibility with poor browser implementations of the HTML5 History API (a misbehaving browser could misinterpret a request for assets/vendor.css while browsing http://site/admin/nested/path as http://site/admin/nested/path/assets/vendor.css), but I have no proof of strange behavior in any browser I have access to. All behavior seems as expected!

One discrepancy that could occur is with upcoming server-side rendering of Ember routes in future Ember versions. In that case, the asset URLs would not match up with the URL of the requested resource, which could cause confusion. I'm grasping at straws here though :)

I foresee problems, but I can't necessarily enumerate any solid cases right now. I'm very biased, but I've always felt using absolute URLs for linking to CSS and JS from HTML was best practice. I totally concede the point that current behavior is as expected.

I appreciate you debating with me about this and the errors I've encountered, and about all the work you've obviously been putting into maintaining this awesome library. Hats off to you.

[patcoll]

I have a script I use to remove all NPM and Bower libs, clear both NPM and Bower caches, then re-install all libs. I ran my server again and the first time the page loads, I still get the error.

[seanpdoyle]

One discrepancy that could occur is with upcoming server-side rendering of Ember routes in future Ember versions.

@patcoll I have some concerns about as well, but given the fact that we're encouraging users to use the render_ember_app, which used the EmberCLI generated index.html, we won't have to worry (we'll benefit from EmberCLI changes for free).

the asset URLs would not match up with the URL of the requested resource

In production systems, most EmberCLI applications will set the fingerprint.prepend option to point to their CDN, so real users shouldn't ever deal with this edge case, only developers running / testing locally (presumably in their "well-behaved browsers").

[seanpdoyle]

I have a script I use to remove all NPM and Bower libs, clear both NPM and Bower caches, then re-install all libs. I ran my server again and the first time the page loads, I still get the error.

The fact that we can't get this to work is disconcerting.

Have you tried using the second commit of https://github.com/seanpdoyle/ember-cli-rails-heroku-example/tree/remove-sprockets as a reference?

[patcoll]

Also FWIW, I never seem to run into the issue in a test environment. All Capybara tests pass in all CI environments we use, so whatever Rack server that Capybara runs (still WEBrick?) doesn't seem to trigger the same behavior that PUMA does.

[seanpdoyle]

@patcoll are you on ScreenHero?

I'm seandoyle at thoughtbot.com if you'd like to try devoting 3 minutes to air pair through this

[patcoll]

I've definitely used that as a reference, indeed, as we've been debating the finer points of relative asset URLs and fingerprinting ;)

Are you talking about seanpdoyle/ember-cli-rails-heroku-example@65b3fd2?

FWIW the Gemfile.lock on that commit references ffb7c2d, which is one commit behind 2b26309, the current HEAD on master.

I'll ping you on ScreenHero in a minute here.

[patcoll]

I was able to avoid this error by ensuring the index.html file exists before the build is declared done. See referenced pull request..

[seanpdoyle]

@patcoll would you mind using this branch of the addon:

rondale-sc/ember-cli-rails-addon#27

I'm very hopeful this will resolve the race condition