Skip to content

Using url in SCSS mixin in another file doesn't import files correctly #7777

Closed

Description

@Dakkers

Reopened from #7598 because I didn't see an option to actually re-open that issue.

Describe the bug

Using an SCSS mixin (located in another file) that uses the url function makes the file unable to be found. Example:

// src/scss/mixins.scss

@mixin next-gen-image ($file-name, $fallback-ext) {
  .webp-supported & {
    background-image: url('#{$file-name}.webp');
  }

  .webp-not-supported & {
    background-image: url('#{$file-name}.#{$fallback-ext}');
  }
}
// src/jsx/routes/Home.scss
@import './../../scss/mixins';

.my-class {
  @include next-gen-image('some-image', 'jpg');
}

This should try to lookup src/jsx/routes/some-image.webp and src/jsx/routes/some-image.jpg but it instead tries to look for src/scss/some-image.webp and src/scss/some-image.jpg respectively.

This was working prior to 3.1.x.

Did you try recovering your dependencies?

yes

Which terms did you search for in User Guide?

N/A

Environment

  System:
    OS: macOS High Sierra 10.13.4
    CPU: (8) x64 Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
  Binaries:
    Node: 10.15.0 - ~/.nvm/versions/node/v10.15.0/bin/node
    Yarn: 1.15.2 - /usr/local/bin/yarn
    npm: 6.6.0 - ~/.nvm/versions/node/v10.15.0/bin/npm
  Browsers:
    Chrome: 76.0.3809.132
    Firefox: 65.0.1
    Safari: 11.1
  npmPackages:
    react: 16.9.0 => 16.9.0
    react-dom: 16.9.0 => 16.9.0
    react-scripts: 3.1.1 => 3.1.1
  npmGlobalPackages:
    create-react-app: Not Found

Steps to reproduce

See code snippet above. Alternatively, see https://github.com/Dakkers/create-react-app-issue-7598

Expected behavior

It should import the local image files correctly

Actual behavior

It does not import local image files correctly

image

Reproducible demo

https://github.com/Dakkers/create-react-app-issue-7598

Activity

  1. robertvansteen commented on Oct 3, 2019

    @robertvansteen
    Contributor

    Have you tried using a relative path instead? Like ./some-image?

  2. Dakkers commented on Oct 3, 2019

    @Dakkers
    Author

    @rovansteen yes; using the code from my example repo and changing the mixin use to:

      @include next-gen-image('./img/dk-kart', 'jpg');
    

    results in the same Can't resolve <...> error

  3. thinkerelwin commented on Oct 5, 2019

    @thinkerelwin

    got similar problems too,

    my case is I've a main scss in 'src/assets/scss/App.scss'

    it contains

    @import "./components/icons";

    then in 'src/assets/scss/components/icons.scss'

    it contains

    .icon-check-o {
      background-image: url(../img/pc_w_icon_condition_done_large.png);
    }
    

    the image is stored in 'src/assets/img/pc_w_icon_condition_done_large.png'

    when I update my react-script from 3.0.1 to 3.2.0, got an error when 'npm run build', says can't find that image

  4. texas697 commented on Oct 15, 2019

    @texas697

    need help as well

  5. tkalliom commented on Oct 24, 2019

    @tkalliom

    I believe this is due to the introduction of resolve-url-loader in #5829 . The motivation of that package is to support a feature-based directory structure, where relative paths in imported scss files are resolved relative to the importee, not the importer. However, as noted at https://www.npmjs.com/package/resolve-url-loader#user-content-mixins that breaks mixins

  6. Dakkers commented on Oct 24, 2019

    @Dakkers
    Author

    it's unfortunate to see that their solution is "You will need to work around this" - how? should I just copy and paste that mixin in every single file? 🤦‍♂

  7. stale commented on Nov 23, 2019

    @stale

    This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

  8. Dakkers commented on Nov 23, 2019

    @Dakkers
    Author
  9. sepehrity commented on Dec 6, 2019

    @sepehrity

    I have the same problem. Any update on this issue?

  10. stale commented on Jan 5, 2020

    @stale

    This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

  11. Dakkers commented on Jan 5, 2020

    @Dakkers
    Author

    it's still an issue 👎

  12. ianschmitz commented on Jan 31, 2020

    @ianschmitz
    Contributor

    Fixed in #8281. Released in 3.3.1

  13. locked and limited conversation to collaborators on Feb 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions