Module not found: Error: Can't resolve file

@angular/cli: 1.0.0-beta.32.3 [1.0.0-beta.28.3]
node: 7.5.0
os: darwin x64
@angular/common: 2.4.7
@angular/compiler: 2.4.7
@angular/core: 2.4.7
@angular/forms: 2.4.7
@angular/http: 2.4.7
@angular/platform-browser: 2.4.7
@angular/platform-browser-dynamic: 2.4.7
@angular/router: 3.4.7
@angular/cli: 1.0.0-beta.32.3
@angular/compiler-cli: 2.4.7

After the update to beta.32.3 i started getting these errors in SCSS files:

ERROR in ./src/app/shared/header/header.component.scss
Module not found: Error: Can't resolve './assets/images/icon-search.png' in '/Users/hassan/Code/app/shared/header'
 @ ./src/app/shared/header/header.component.scss 6:1898-1940
 @ ./src/app/shared/header/header.component.ts
 @ ./src/app/shared/shared.module.ts
 @ ./src/app/app.module.ts
 @ ./src/main.ts
 @ multi webpack-dev-server/client?http://localhost:4200/ ./src/main.ts

ERROR in ./src/app/shared/nav/nav.component.scss
Module not found: Error: Can't resolve './assets/fonts/portal.eot?' in '/Users/hassan/Code/src/app/shared/nav'
 @ ./src/app/shared/nav/nav.component.scss 6:295-332
 @ ./src/app/shared/nav/nav.component.ts
 @ ./src/app/shared/shared.module.ts
 @ ./src/app/app.module.ts
 @ ./src/main.ts
 @ multi webpack-dev-server/client?http://localhost:4200/ ./src/main.ts

The error seems to appear in this line:

background-image: url('assets/images/icon-search.png');

P.S: It was working fine on beta.31

Same thing here. Technically, at development time, the path is wrong because the file has not yet been compiled into the location it will be at runtime. So I'm assuming I need to specify the location in the configuration somewhere?

For reference my .angular-cli.json file has:

"assets": [
        "assets",
        "web.config"
      ],

(Which was working fine in beta.31 as mentioned earlier)

I've got the same; still getting the error

me too
@font-face { font-family: 'Segoe UI'; src: url('../assets/fonts/SegoeUI.eot'); src: url('../assets/fonts/SegoeUI.eot?#iefix') format('embedded-opentype'), url('../assets/fonts/SegoeUI.woff') format('woff'), url('../assets/fonts/SegoeUI.ttf') format('truetype'); font-weight: normal; font-style: normal; }

ERROR in ./src/app/components/footer/footer.scss Module not found: Error: Can't resolve '../assets/fonts/SegoeUI.eot' in '/home/arman/Projects/AOP/src/app/components/footer' @ ./src/app/components/footer/footer.scss 6:83-121 6:144-182 @ ./src/app/components/footer/footer.ts @ ./src/app/index.ts @ ./src/main.ts @ multi webpack-dev-server/client?http://localhost:4200/ ./src/main.ts

CSS URL handling was changed. To replicate the behavior prior to beta.32, use a root relative URL (i.e., add a / to the beginning of each URL).

I tried that and it did compile with no errors, but then at runtime it was looking for 'assets' in the root of the url rather than in the root of the web context. So none of my images loaded.....

@clydin

Thanks @clydin - it started working again for me by adding '/' before all relative URLs in the SCSS files.

@billdwhite do you have the 'assets' in your .angular-cli.json file as mentioned above?

Yes I do have that in my files. But I'm running the app from a subcontext (think http://myserver/myapp as opposed to http://myserver) so the path that results from using / before the relative urls results in it looking for http://myserver/assets/myimage.png which is wrong. (It needs to be http://myserver/my app/assets/myimage.png) so I'm guessing I'm missing some other config setting that tells it to adjust for that. Maybe base href or something but that seems to be set correctly for everything else in my app so I'm not sure what I'm missing. Again, setting the / does fix the compile errors but it just doesn't work at runtime.

@billdwhite

I have the exact same behaviour as @billdwhite. Adding a slash maybe fixes the compilation error but it's no final solution and wasn't necessary in the past.

@filipesilva

@filipesilva is it possible this was caused by your commit from 3 days back?

Yes it is likely related. I'll have a look.

url()'s in component stylesheets are now processed. This allows the CLI to hash the assets and supports long-term caching. However, the URL now needs to be build-time discoverable and the path must be relative to the component stylesheet for this to work. This also has the advantage that component based assets can be encapsulated within the component source location, if desired.

If you don't want them processed, a root relative URL will prevent this behavior. Unfortunately, this will currently conflict with custom base hrefs and deployUrls. This is in the process of being corrected.

Also of note is that global stylesheets already function in this manner.

@billdwhite

I'm running Angular CLI version 6.2.4 and I still have the same issue reported before by @billdwhite:

Yes I do have that in my files. But I'm running the app from a subcontext (think http://myserver/myapp as opposed to http://myserver) so the path that results from using / before the relative urls results in it looking for http://myserver/assets/myimage.png which is wrong. (It needs to be http://myserver/my app/assets/myimage.png) so I'm guessing I'm missing some other config setting that tells it to adjust for that. Maybe base href or something but that seems to be set correctly for everything else in my app so I'm not sure what I'm missing. Again, setting the / does fix the compile errors but it just doesn't work at runtime.

this happens only in production and only when the app runs in a subdomain.

Just want to add another vote.. because paths in my scss is also not working for me. If I do not absolute it works when running with ng serve but not in prduction and the other way around when I go relative. This the line in one of my components scss files: background-image: url("assets/bar.png");

EDIT:
actually I just found I had another bug in my scss, which was the real cause for it not working in production. I had:

background: cover #da4877;
background-image: url("/assets/bar.png");
background-size: cover;

after I changed the first line to background: #da4877; it works.

So please Ignore my vote on this ;)

@billdwhite

I'm running Angular CLI version 6.2.4 and I still have the same issue reported before by @billdwhite:

Yes I do have that in my files. But I'm running the app from a subcontext (think http://myserver/myapp as opposed to http://myserver) so the path that results from using / before the relative urls results in it looking for http://myserver/assets/myimage.png which is wrong. (It needs to be http://myserver/my app/assets/myimage.png) so I'm guessing I'm missing some other config setting that tells it to adjust for that. Maybe base href or something but that seems to be set correctly for everything else in my app so I'm not sure what I'm missing. Again, setting the / does fix the compile errors but it just doesn't work at runtime.

this happens only in production and only when the app runs in a subdomain.

Hey, did you find any solution for this issue? I'm facing the same issue.

@isahilpahuja

@isahilpahuja , the workaround (not a proper solution) I've found is to move your image reference from the styles to the template. It feels icky but it "works."

So instead of:

// article.scss
.article__photo {
  background-image: url(assets/bacteria.svg);
}

do this instead:

<!-- article.html -->
<div class="article__photo" style="background-image: url(assets/bacteria.svg);"></div>

Though this workaround may not be reasonable if you're wanting to apply the background image to many elements.

Another possible workaround is to eject the webpack config and fiddle with the CSS file-loading, though I'm no webpack expert but I assume it could likely be done... Of course, at the expense of the ejected webpack config which I personally find intimidating...

@Empereol

@Empereol Thanks a lot! I moved it from styles to template and it worked. But still didn't able to find the reason why it was not working when placed in scss file.

Test scss file with background image. Working. Make modification so a…

Any update on this? This problem has been there very long now and it's still not being addressed. I was not able to find clean way to reference assets in scss files that would work both for dev and production. Absolute path works in dev environment but not in prod when application is hosted in subdomain, relative path on the other hand forces me to reference different path depending on location of scss file.

The problem still is here - Jun 2019
But I found lukaszmn's solution can solve the issue with background: url("~src/assets/foo.svg") instead of url(/assets/foo.svg).

This was working for me just fine in Angular7 with the url('/assets/foo.png'). As soon as I migrated to Angular 8 It broke again, and I must use url('~src/assets/foo.png').

Any news?

Until now I have faced the same problem. url("/assets/...") worked well with ng serve but not on my production server with an different base-href than "/". It redirected to <domain>/assets/.. instead of <domain>/<subfolder>/assets (<domain>/<subfolder>/ is my base-href).

~~Now I can confirm the following using Angular 8:~~

~~"/assets/..." in url() is an absolute path from the host URL.~~

~~"assets/..." in url() is an relative path to the base-href you set.~~
both are the absolute paths from the host URL, not from the base-href URL.

I'm now using just "assets/..." and it works for me on development and production.

EDIT: I don't know why, but my images are copied next to the assets folder but there are copies in my assets folder, too. Does anyone knows the reason?

@julianpoemp

I'm now using just "assets/..." and it works for me on development and production.

EDIT: I don't know why, but my images are copied next to the assets folder but there are copies in my assets folder, too. Does anyone knows the reason?

@julianpoemp this is well explained above #4778 (comment), url() in component styles is processed.

@clydin

Problem

I am having a similar problem; ng serve works fine, but the CSS produced by ng build --base-href="./" transforms url()'s from url(/fonts/roboto/roboto-latin.woff2) to url(/./fonts/roboto/roboto-latin.woff2) (notice the root-relative slash). The desired output would be url(./fonts/roboto/roboto-latin.woff2) (a relative url) which should result in the browser loading it relative to the HTML's <base href="./">.

I have manually replaced the url(/./ with url(./ and seen the CSS load properly based on the <base href>, and am struggling to figure out how to configure the Angular CLI (6.2.9) to produce relative url()s.

More details:

We build artifacts without knowing where they will be deployed. Deploying artifacts involves setting the <base href> appropriately, so all resources are relative to the correct base.

I have read the responses by @clydin #4778 (comment), and @filipesilva #4778 (comment), but find them confusing because:

my problem is with styles.css not a component
those comments are over 2 years old
there is talk about This is in the process of being corrected.
confusing wording like fixed url(), does fixed mean "to resolve a problem" or "a non-relative path"

I have read (webpack-contrib/extract-text-webpack-plugin#246 (comment)) that disabling the url processing by the css-loader is a solution, but haven't tried it out yet. After 2 years of this problem, I would be surprised if the Angular CLI didn't have first-class support for this.

Does the Angular CLI have a solution to this problem, or is a custom Webpack Config the "correct" solution? If yes, then what version of the Angular CLI supports the solution (since we are using v6)?

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}

fix(@angular/cli): fix css url processing (angular#4803)

Navigation Menu

Repository navigation

Module not found: Error: Can't resolve file #4778

32 remaining items

Problem

More details:

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Module not found: Error: Can't resolve file #4778

Description

Activity

billdwhite commented on Feb 17, 2017

hassanasad commented on Feb 17, 2017

billdwhite commented on Feb 17, 2017

armangevorgyan commented on Feb 17, 2017

clydin commented on Feb 17, 2017

billdwhite commented on Feb 17, 2017

hassanasad commented on Feb 17, 2017

billdwhite commented on Feb 17, 2017

kunee commented on Feb 17, 2017

billdwhite commented on Feb 17, 2017

filipesilva commented on Feb 17, 2017

clydin commented on Feb 17, 2017

32 remaining items

FrancescoBorzi commented on Oct 5, 2018

matulkum commented on Oct 7, 2018

isahilpahuja commented on Nov 3, 2018

Empereol commented on Nov 7, 2018

isahilpahuja commented on Nov 27, 2018

thorhunter1 commented on Dec 14, 2018

hieutranagi47 commented on Jun 4, 2019

fergardi commented on Jul 5, 2019

julianpoemp commented on Jul 7, 2019

royling commented on Aug 13, 2019

Paitum commented on Aug 25, 2019

Problem

More details:

angular-automatic-lock-bot commented on Sep 25, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions