Webpack - ignore loaders in require()?

Question

I have a TypeScript project which I am bundling with Webpack. It is a demo/docs app for an open source lib I am writing, so I want to show some of the source code as part of the docs.

In my webpack config I have:

 loaders: [
   { test: /\.ts$/, loader: 'ts'},
   { test: /\.css$/, loader: 'style!raw' },
   { test: /\.html/, loader: 'html' }
 ]

which works fine for transpiling and bundling my TypeScript files. In one of my app components I do this:

basicCodeT: string = require('./basic-example-cmp.html');
basicCodeC: string = require('!raw!./basic-example-cmp.ts');

to load the source code into a string which I then want to display in the docs.

As you can see, there is a leading ! in the second line which I discovered seems to "bypass" the default loaders from the config and loads the raw TypeScript as a string.

In my dev build this works, but when I do a "production" build with the UglifyJsPlugin and OccurrenceOrderPlugin, I get the following output:

ERROR in ./demo/src/basic-example-cmp.html
Module build failed: 
@ ./demo/src/demo-app.ts 24:26-61

which corresponds to the line in the source where I try to require the raw TypeScript.

So, I want to pass basic-example-cmp.ts through the TS compiler as part of the app build, but also want to require it as raw text in the app.

My question then is: Is there a proper way to tell webpack to "ignore" loaders in specific require cases?

Is my way of prepending a ! correct? Is it a hack?

Update

Turns out my problem is simply due to the way Webpack handles HTML templates - it does not like the Angular 2 template syntax, see: https://github.com/webpack/webpack/issues/992

Answer 1

You can add two exclamation to ignore loaders in the webpack config file

!!raw!file.ts

one exclamation will only disable preloaders!

https://webpack.js.org/concepts/loaders/#inline

Answer 2

As far as I know that is the only way you are going to be able to load a file in two different ways. I expect the issue is that your paths are different in your production build.

I would suggest running webpack with the --display-error-details flag to get more info on why it fails.