[REPRO] Lookup paths differ between eager and lazy

[chadhietala]

This is a repro of a failure scenario. It illustrates that there appears to be different resolution between eager and lazy when using asset-url.

Steps to repro:

1. Checkout this branch then yarn && ember s
2. Visit /lazy
3. Notice that the SVG downloads that was declared as asset-url('img/test.svg')
4. Visit /eager
5. Notice that the image 404s that was declared as asset-url('img/test.jpg')

Any attempt to change the path to something like eager/assets/img/test results in

error in C function eyeglass-asset-uri: Asset not found: eager/assets/img/test.jpg
    at /Users/chietala/Code/ember-cli-eyeglass/node_modules/eyeglass/sass/assets.scss:73:7

However this is exactly where the file is being served from. What is the correct way for referring to static files so that they resolve correctly?

[stefanpenner]

Thanks for the reproduction!

[stefanpenner]

No solution yet, just writing down my observations of the current state:

Contents of public (fonts/images) ends up in:

type	input	output
App	:root/public	dist/<here>
Addon	:root/public	dist/:addon-name/assets/<here>
Eager Engine	:root/public	dist/:addon-name/assets/<here>
Lazy Engine	:root/public	dist/engine-dist/:addon-name/assets/<here>

Eyeglass process CSS:

type	input	output
App	:root/app/styles	dist/<here>
Addon	:root/addon/styles	dist/:addon-name/assets/<here>
Eager Engine	:root/addon/styles	dist/assets/:addon-name.css
Lazy Engine	:root/addon/styles	dist/engine-dist/:addon-name/assets/engine.css

Within: tests/dummy/lib/lazy/addon/styles/addon.scss

• asset-url('img/test.svg') is valid from eyeglass's perspective
• img/test.jpg resides at /dist/engines-dist/lazy/assets/img/test.svg (as expected)

Within: tests/dummy/lib/eager/addon/styles/addon.scss

• asset-url('img/test.svg') is valid from eyeglass's perspective
• img/test.jpg resides at: /dist/eager/assets/img/test.jpg <-- conflict
• img/test.jpg is expected to reside at /dist/assets/img/test.jpg <-- conflict

---

The conflict appears to be that, static assets output differ between add-ons and lazy engines. It appears as the lazy-engine scenario is functioning with the least surprises.

Some thoughts:

• engines regardless of lazy or eager should store their individual assets in the same location.
• either move engines to engines-dist (both lazy and eager) or have them reside in dist/:addon-name/assets/<here>
• an ideal solution if possible would be to simply store all assets regardless of eager/lazy in dist/:addon-name/assets/<here>

[stefanpenner]

@chadhietala I realize my comment doesn't unblock you yet as the eyeglass assertion prevents the obvious work-around. Now that I have a basic clear idea of what is happening, I'll take a stab at your exact issue.

[mahirshah]

If I remember correctly the issue resides in getDefaultAssetHttpPrefix, where we check if its a lazy engine and set the assetHttpPrefix to engines-dist/<addon>/assets. If we remove the engines-dist portion from the default asset-url, I think that would get both lazy and eager engines to build to dist/:addon-name/assets/<here>

[chriseppstein]

Possibly related to #46

[chriseppstein]

After investigating this, I've uncovered a number of issues that need to be addressed in concert.
#52

In terms of this reproduction, @chadhietala, I don't really understand what the use case is for using asset-url() for this addon's code. It seems like a normal css url() to the well known location of the addon's public assets would be more than sufficient.

asset-url() exists for stylesheets that are built outside the context of a specific application plugin or build infrastructure, to insulate the stylesheet author from the variety of possible approaches that exist across application frameworks and build tools.