Treat all unknown extensions as resources

@dralletje

I’m getting a bit tired of extending our whitelist like in #665.
I think we should have a “catch all” loader that uses file-loader for any unknown extensions.

This makes sense because it’s easy to explain: “if you import something that isn’t JS or CSS, it becomes a part of the build, you get its filename, and can do whatever with it”.

I think @dralletje planned to look into this.

Looking at webpack.config.dev.js, I'm wondering: why use url-loader for audio / video, but file-loader for images? In the scenarios I'm most familiar with, you'd usually do the complete opposite of that: you want essential images, like sprite sheets, to load immediately, but sound and video can wait.

I think this using file-loader for unknown resources is a good default.

Looking at webpack.config.dev.js, I'm wondering: why use url-loader for audio / video, but file-loader for images?

I didn’t really think it through. If you have better ideas for defaults please submit a PR.

@gaearon

@gaearon Any word on this? I wanted to use a php file, to ajax from a form. But I have to manually copy it over after the build process since there's no included loader for php

@iRoachie

@iRoachie I think any backend files (like php) should live outside the project folder. The project folder is only meant to be for files related to the front-end client-side app.

This is a good example of working with backend APIs. It assumes Node but PHP would work similarly.

How's this similar to PHP? I'm using the php to send and email when the data from the form is posted. The link you provided assumes using Node and using endpoints to access the data.

By similar I meant that, like in that tutorial, you can put client and server code in the different folders, and you can use proxy in development to call /mybackend.php which would get resolved to the specified port. In production, you can have index.php serve built index.html.

@gaearon

@gaearon I messaged you on twitter

This is interesting. We are having the same issue with the angular-cli. In my opinion, regardless of "how" you treat the file (emitted with file-loader into dist, or converted to js, etc), my opinion is that you want it managed by webpack in some way or another.

A catchall unknown-source loader feels like it would be pretty beneficial. I wonder if perhaps leveraging the include property on the loader object to pass a Regex of a folder path like ./assets or w/e.

@fson

@fson, @gaearon I can take this if we agree on a few assumptions:

I don't think we should rely on naming conventions. When loading a .png and .svg works, loading a .bmp should really not feel any different to a developer. Instead, I suggest that we load anything in /src that's not already addressed by another loader.
@cesarandreu why not preferring the url-loader with 10k limit for unmatched files?
I don't think there's an explicit "use this loader if no other addresses it", so I'll suggest using a test regex with a negative lookahead. Unfortunately that'll require re-typing all the file extensions handled by other loaders, but it looks like a small price to pay, I can add comments.
While at it, if everyone agrees I'll move all items that are currently handled by file loader to url-loader as well per @cesarandreu suggestion.

Fixed by #1059 & #1077.

@cpojer

Turns out our regex in the Jest moduleNameMapper config didn't work as we had thought, which caused issues when JS files with . in the module name were treated as file resources and stubbed (#1145, #1147).

As a stopgap measure, I reverted the Jest config back to the previous regex which whitelists non-JS/CSS extensions separately, but we still need to find a way to get the same behaviour as our Webpack configuration in Jest.

Maybe @cpojer can help us here? We're trying to create a Jest config that matches this Webpack config:

module: {
  loaders: [
    {
      exclude: [
        /\.html$/,
        /\.(js|jsx)$/,
        /\.css$/,
        /\.json$/
      ],
      loader: 'url',
      ...
    },
    {
      test: /\.(js|jsx)$/,
      include: paths.appSrc,
      loader: 'babel',
      ...
    },
    {
      test: /\.css$/,
      loader: 'style!css?importLoaders=1!postcss'
    },
    {
      test: /\.json$/,
      loader: 'json'
    }
  ]
},

Files with .js, .css and .json extensions are handled separately. Everything else is treated as a file – they should be stubbed in Jest.

The first attempt was a regex with a negative lookahead like this:

moduleNameMapper: {
  '^.+\\.(?!(js|jsx|css|json)$)[^\\.]+$': resolve('config/jest/FileStub.js'),
  '^.+\\.css$': resolve('config/jest/CSSStub.js')
}

However, this doesn't work because moduleNameMapper matches the module name, not the absolute file path like Webpack. Because JS files can be imported without specifying the extension, the module name doesn't necessarily end with .js. This caused false positives where imports like import assign from 'lodash.assign' or import a from '../a' were stubbed.

Is it even possible at the moment to replicate this Webpack config in Jest? I think being able to somehow match against the absolute file path would be necessary for that.

@cpojer

What @cpojer told me:

The idea is to use the new transform field we added in 17

You can run any transformer on any regex

Default is babel-jest for JS

But you can build a sync transformer for css

Thanks Dan for sharing my messages to you. Yes, the transform field is meant to be used for this. If you guys are building css-jest and scss-jest and all, I'm happy to support this officially in Jest – this was my long term plan so we can also have style information in JS, just like we do in react-native:

<View
  style={{
    color: 'green',
  }}
/>

etc.

Navigation Menu

Repository navigation

Treat all unknown extensions as resources #667

12 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Treat all unknown extensions as resources #667

Description

Activity

cesarandreu commented on Sep 18, 2016

gaearon commented on Sep 18, 2016

iRoachie commented on Sep 21, 2016

gaearon commented on Sep 21, 2016

gaearon commented on Sep 21, 2016

iRoachie commented on Sep 21, 2016

gaearon commented on Sep 21, 2016

iRoachie commented on Sep 21, 2016

TheLarkInn commented on Oct 7, 2016

bebbi commented on Nov 18, 2016

12 remaining items

fson commented on Nov 22, 2016

fson commented on Dec 4, 2016

gaearon commented on Dec 5, 2016

cpojer commented on Dec 5, 2016

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions