Skip to content

using image [src] with require to load images requires .default suffix #17400

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
2 of 15 tasks
victor-ca opened this issue Apr 6, 2020 · 2 comments
Closed
2 of 15 tasks

Comments

@victor-ca
Copy link

victor-ca commented Apr 6, 2020

🐞 Bug report

Command (mark with an x)

  • new
  • build
  • serve
  • test
  • e2e
  • generate
  • add
  • update
  • lint
  • xi18n
  • run
  • config
  • help
  • version
  • doc

Is this a regression?

Yes, the previous version in which this bug was not present was: angular & cli <9.1.0

Description

binding image [src] to a source using "require()" longer works unless ".default' suffix is present;
ex:

export class TestComponent {
  sun = require('./sun.svg');
 // [...]
 <img [src]="sun" >

🔬 Minimal Reproduction

  1. setup the test app
 ng new test-app
curl -Ll https://upload.wikimedia.org/wikipedia/commons/e/e8/Heraldic_Sun.svg -o ./test-app/src/app/sun.svg
cd  test-app
ng serve
  1. edit app.component.ts
import { Component } from '@angular/core';
declare const require: any;

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})
export class AppComponent {
  sun = require('./sun.svg');
}

and replace app.component.html with

<img [src]="sun" />

🔥 Exception or Error

there will be no exception however rather than requiring the img a request to http://localhost:4200/[object%20Module]
will be made;

changing the require like this:

  sun = require('./sun.svg').default;

works however previously it worked without this;
this gets fixed if file-loader's esModule is set to false which i did using a custom angular-builders/custom-webpack like this

const isImgLoader = (rule) =>
  rule.test &&
  rule.loader &&
  rule.test.toString().includes('svg') &&
  rule.loader.toString().includes('file-loader');

const patchFileLoader = (rule) => ({
  ...rule,
  options: {
    ...rule.options,
    esModule: false, // <------ here
  },
});

module.exports = (config) => {
  return {
    ...config,
    module: {
      ...config.module,
      rules: config.module.rules.map((r) =>
        isImgLoader(r) ? patchFileLoader(r) : r
      ),
    },
  };
};

🌍 Your Environment




Angular CLI: 9.1.0
Node: 12.16.1
OS: darwin x64

Angular: 9.1.0
... animations, cli, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router
Ivy Workspace: Yes

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.901.0
@angular-devkit/build-angular     0.901.0
@angular-devkit/build-optimizer   0.901.0
@angular-devkit/build-webpack     0.901.0
@angular-devkit/core              9.1.0
@angular-devkit/schematics        9.1.0
@ngtools/webpack                  9.1.0
@schematics/angular               9.1.0
@schematics/update                0.901.0
rxjs                              6.5.5
typescript                        3.8.3
webpack                           4.42.0

Anything else relevant?

of course it can be fixed adding this change in packages/angular_devkit/build_angular/src/angular-cli-files/models/webpack-configs/common.ts i might check this later and add a PR

vue had smth similar

@filipesilva
Copy link
Contributor

Hi there,

While using require() for images does work, this isn't something we've ever explicitly supported. Instead, Webpack, which we use, supports it, and we don't prevent its usage. In general we don't encourage or support using non-standard and webpack-specific features directly in user source code, because we don't want to commit to supporting them in case we change to other build setups.

In this case changing your require usage sounds like the right approach because otherwise we'd be half-heartedly trying to support something we don't support in the first place, and might even break other supported cases while trying.

@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators May 7, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants