[error] asset not found: ./node_modules/font-awesome/css/font-awesome.css about webpack-isomorphic-tools HOT 36 CLOSED

hmm...
so, first of all, somebody requires "./node_modules/font-awesome/css/font-awesome.css" in code.
who is that?
seems that it is react-fa module:
https://github.com/andreypopp/react-fa/blob/master/src/index.js#L5

import 'font-awesome/css/font-awesome.css';

But why do they import a .css file in Node.js?
I don't get it: one can only import javascript files and importing a .css file would result in a syntax error.
So, this is the thing: this react-fa module is conflicting with webpack-isomorphic-tools loader.
Regardless of why on Earth do they require that css file, what you can do is add this file to exceptions
https://github.com/halt-hammerzeit/webpack-isomorphic-tools/blob/master/source/index.js#L235-L239

..., exceptions: ['./node_modules/font-awesome/css/font-awesome.css'], ...

from webpack-isomorphic-tools.

I added the file to exceptions before posting this issue and it broke my build.

The CSS file is for a react component -- often loaded via webpack.

I'm aiming to build an isomorphic application where both client and server will need this react-fa component.

I'm probably better off ecluding the css file from my webpack config's loaders and requiring it from an entry point?... although this doesn't appeal as it's more config and manual dependency management --- also my isomorphic app works just fine right now -- other than this error

from webpack-isomorphic-tools.

If adding the file to exceptions broke your build then it's likely that you require it yourself somewhere in your code (maybe you @import it somewhere in your styles).
But at the same time you have include: [/src\/app/, /awesome/], which means that file ./node_modules/font-awesome/css/font-awesome.css can't be required from your files because webpack won't find it (it is excluded from webpack in your config).
So I don't understand: are you including this file inside your project manually?
If you are then you are unable to add it to exceptions.
But at the same time you can't be including this file inside your project because your webpack config prohibits that.
There's a logical contradiction in what you are saying me and I don't understand.

from webpack-isomorphic-tools.

I'm not including this file myself, I'm including react-fa... The include regex that the module loader specifies doesn't include the .css file, it just allows for it to be included in the module processing of CSS... I'd also removed that include /awesome/ regex when adding it to the isomorphicConfig's exclude array.

from webpack-isomorphic-tools.

Have you tried leaving that include /awesome/ regex in your webpack config while adding the file to the exclusions array?

from webpack-isomorphic-tools.

Yes

from webpack-isomorphic-tools.

Well, I guess I could try to run your project if you give me the code and running instructions.

from webpack-isomorphic-tools.

It's behind an NDA sorry. I'll want to open sourcing something similar within the next few weeks hopefully -- but my aim was to remove this error first.

FWIW, my own components require SCSS files just fine on the server using webpack-isomorphic-tools.

from webpack-isomorphic-tools.

I've had another look on react-fa and now I think it's definitely meant for client side only.
Because they import a css file - you can't do that on server because it'll break Node.js
So the reason is that.

Why doesn't it crash in your case?
Because you use webpack-isomorphic-tools and it handles that import on server.
Anyway that import isn't doing anything on server: it's for client side only, it's only there to add that css file to client side webpack bundle.
So it works.

And now I know why it breaks when you add it to exceptions: because in that case Node.js falls back to normal require which crashes because of a syntax error.

So, the issue is resolved now.

from webpack-isomorphic-tools.

Yes that's right, it's necessary to add the css file to the client side bundle...

But the react-fa is needed in my isomorphic application.. if I remove it from the server's render --- then the client and server rendered code go out of sync... and new errors are now showing in the client.

Why would WIT give an error for react-fa importing the css file but not my own files that require css modules?

This isn't a closed issue :S How can I prevent the error?

from webpack-isomorphic-tools.

As I've said, react-fa is meant for client side webpack build only.
The author of the library made it that way.
For it to work on server he can replace that import with some other mechanism of requiring that css file (and he can't simply require in on server).

The issue is totally resolved because I found the root cause - it's the react-fa module and I'm not maintaining that.

from webpack-isomorphic-tools.

ok ty

from webpack-isomorphic-tools.

As for the possible solution you can propose the author of react-fa package to possibly replace that line
https://github.com/andreypopp/react-fa/blob/master/src/index.js#L5
with that:

// detect webpack
if (require.include)
{
  require('font-awesome/css/font-awesome.css');
}
else
{
  // do nothing on server side
}

from webpack-isomorphic-tools.

Might it be possible to add module stub functionality to webpack isomorphic tools?

Some area in the config to ignore imported assets without resorting to the native node require?

from webpack-isomorphic-tools.

@tomatau I would add that kind of functionality if you give me enough reason. Right now that would be just an amateurish hack to make a totally different 3rd party library work on server and that's not what I'm ever gonna do.

from webpack-isomorphic-tools.

You could write your own require server side hook though, just for this specific file (if you wish to introduce that sort of hackery into your code).
That way, when webpack-isomorphic-tools finds an exception it would fallback to your default loader for .css files which could do whatever it can: for example, return a stub.
You can copy-paste my code, the module is not so large.

from webpack-isomorphic-tools.

import hook      from './tools/node-hook'

hook.hook(`.css`, (asset_path, fallback) =>
{
            this.log.debug(`require() hook fired for ${asset_path}. Returning a stub`)
            return undefined
})

from webpack-isomorphic-tools.

Throughout my codebase I would like to require assets to components to be explicit about their dependencies. It's fine to use CSS modules for these imports but this isn't ideal for code optimisation.

Also having those components work in both the server and client is the goal for isomorphic rendering.

Using something like the below, or even a custom module that wraps around the same functionality:

if (__BROWSER__ || require.include) require('somefile.css')

Seems like boilerplate that defeats a lot of the purpose for an important use case of WIT.

I expect other Components will no doubt want to require CSS at build time and it would be suitable to e.g. ignore all asset requires under /node_modules/ for example.

from webpack-isomorphic-tools.

Hmm, actually, ignoring requires under /node_modules/ is a good idea, I might do that.

from webpack-isomorphic-tools.

Oh, no, wait, that would just fallback and give you the same syntax error.

from webpack-isomorphic-tools.

Stub filters would be really great here... then stubbing node modules and my own client app root would allow for my client side code to work inside WIT with minimal configuration.

from webpack-isomorphic-tools.

if (__BROWSER__ || require.include) require('somefile.css') I didn't propose that. I'm against that, obviously. That's the reason I wrote this module

from webpack-isomorphic-tools.

So, to sum it up, you have two possible solutions:

1. Modify react-fa to work on server side and submit a PR to the author
2. Write your require hook for .css files which will return stubs and add that .css file to exceptions in webpack-isomorphic-tools

import hook      from './tools/node-hook'

hook.hook(`.css`, (asset_path, fallback) =>
{
            console.log(`require() hook fired for ${asset_path}. Returning a stub`)
            return undefined
})

from webpack-isomorphic-tools.

thanks, I'll definitely be looking into the node-hook solution, wasn't aware of this module 👍

from webpack-isomorphic-tools.

This works but still would require an exclude being specified for each component in my codebase that has a CSS dependency that can't be met as a css module.

Could the WIP exceptions array accept regex?

from webpack-isomorphic-tools.

Yeah, I guess I'll do that right now

from webpack-isomorphic-tools.

Thanks that's amazing cheers buddy you're a star!

from webpack-isomorphic-tools.

npm install webpack-isomorphic-tools@latest --save
try that

from webpack-isomorphic-tools.

Oh, and i forgot to mention: it's "exclude" now

On Saturday, September 26, 2015, Thomas [email protected] wrote:

Thanks that's amazing cheers buddy you're a star!

—
Reply to this email directly or view it on GitHub
#4 (comment)
.

from webpack-isomorphic-tools.

This works well, thanks

from webpack-isomorphic-tools.

@tomatau I know it's been a while but I'm bumping into similar setup with react-fa. Would you be able to elaborate on your solution to workaround this? My goal would be to continue to use react-fa in the client while still having universal components rendered on the server.

I assume you went with the node-hook solution to bypass your error which I believe is what I need to do also.

from webpack-isomorphic-tools.

FYI
I'm posting this in every issue and PR to notify whoever may be interested:
today I've released an alternative helper library called universal-webpack.
It takes a different approach than webpack-ismorphic-tools and instead of hacking Node.js require() calls it just compiles all code with target: 'node' webpack configuration option.
As a result, all Webpack plugins and features are supported.
If you think you might need that here's an example project:
https://github.com/halt-hammerzeit/webpack-react-redux-isomorphic-render-example

from webpack-isomorphic-tools.

@halt-hammerzeit - looks nice. Are you still going to continue support for webpack-isomorphic-tools?

I'm guessing universal-webpack wouldn't offer any useful support for a node build that only uses babel (not webpack) needing assets generated from a clientside webpack bundle? Currently webpack-isomorphic-tools achieves this really well!

from webpack-isomorphic-tools.

@tomatau Yeah, webpack-isomorphic-tools are still supported. I wrote universal-webpack for those people who say that webpack-isomorphic-tools is a hack and those who need various exotic Webpack plugins in their server side code (webpack global variables, advanced module resolvers, etc).

from webpack-isomorphic-tools.

Ahh fair call! I use babel-plugins for those things :) Thanks!

Also, it may be a hack, but it's a damn fine hack! Big impact on the potential for high standard applications! Really appreciate it!

from webpack-isomorphic-tools.

@tomatau thanks

from webpack-isomorphic-tools.