Skip to content
This repository has been archived by the owner on May 29, 2019. It is now read-only.

Entry chunks for .css files also creating .js files #518

Closed
AnalogMemory opened this issue May 29, 2017 · 15 comments
Closed

Entry chunks for .css files also creating .js files #518

AnalogMemory opened this issue May 29, 2017 · 15 comments

Comments

@AnalogMemory
Copy link

My config file is working fine. But I've just noticed it's generating extraneous files based on the entry points. The entry for login generates the correct .css file from the .scss file but also creates a login.js file (it essentially has an empty function inside it). Is there a way to prevent this?

Currently using Webpack 2.6.0 and Extract Text Webpack Plugin 2.1.0

const path = require('path');
const webpack = require('webpack');

const ExtractTextPlugin = require('extract-text-webpack-plugin');

module.exports = {
  context: path.resolve(__dirname, './.'),
  entry: {
    'main': [
      './js/main.js',
      './sass/main.scss',
    ],
    'login': './sass/admin/login.scss',
  },
  output: {
    path: path.resolve(__dirname, '../public'),
    publicPath: '/public/',
    filename: 'scripts/[name].js'
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: [/(node_modules|bower_components)/],
        use: [
          {
            loader: 'buble-loader',
            options: {
              objectAssign: 'Object.assign'
            },
          }
        ],
      },
      {
        test: /\.(sass|scss)$/,
        use: ExtractTextPlugin.extract({
          use: [
            'css-loader',
            'sass-loader'
          ]
        })
      },
    ]
  },
  resolve: {
    modules: [
      "node_modules"
    ],
  },
  plugins: [
    new ExtractTextPlugin({
      filename: 'styles/[name].css',
      allChunks: true,
    }),
  ]
}

Here's what the extraneous login.js file contains:

!function(e){function n(r){if(t[r])return t[r].exports;var o=t[r]={i:r,l:!1,exports:{}};
return e[r].call(o.exports,o,o.exports,n),o.l=!0,o.exports}var t={};
n.m=e,n.c=t,n.i=function(e){return e},n.d=function(e,t,r){n.o(e,t)||Object.defineProperty(e,t,{configurable:!1,enumerable:!0,get:r})},n.n=function(e){var t=e&&e.__esModule?function(){return e.default}:function(){return e};
return n.d(t,"a",t),t},n.o=function(e,n){return Object.prototype.hasOwnProperty.call(e,n)},n.p="/public/",n(n.s=5)}({5:function(e,n){}});
@michael-ciniawsky
Copy link
Member

Sadly not with the current implementation, webpack 'natively' only understands JS and will emit a JS file with the code that gets added to the chunk by webpack into a separate .js file, I don't recommend to use any non JS file as an entry point in general, require/import in a JS entry is the better solution for non-JS resources atm. This may change in the intermediate future https://medium.com/webpack/the-new-css-workflow-step-1-79583bd107d7

@hackingbeauty
Copy link

This issue is unfortunate.

@sscaff1
Copy link

sscaff1 commented Nov 30, 2017

@AnalogMemory @hackingbeauty I was able to get around this problem by using https://github.com/AnujRNair/webpack-extraneous-file-cleanup-plugin. I have a pull request in to clean up files specified only in particular files.

@hackingbeauty
Copy link

hackingbeauty commented Nov 30, 2017

To add to the conversation, I was able to successfully remove the redundant JS via these 2 Webpack plugins:

...
new HtmlWebpackPlugin({
  excludeAssets: [/index.js/]
}),
new HtmlWebpackExcludeAssetsPlugin()
...

Check out the HtmlWebpackExcludeAssetsPlugin here:
https://www.npmjs.com/package/html-webpack-exclude-assets-plugin

@hyzhak
Copy link

hyzhak commented Dec 21, 2017

@hackingbeauty sadly this solution doesn't remove unwanted js files, just exclude them from generated html. And won't work without HtmlWebpackPlugin plugin.

@hyzhak
Copy link

hyzhak commented Dec 21, 2017

@sscaff1 why do we want to stick to a size of a file? Why don't use a filename instead?

@sscaff1
Copy link

sscaff1 commented Dec 21, 2017

@hyzhak the size seemed weird to me too. I submitted a PR (which was accepted and published) to eliminate files from a particular path. That satisfied my use case. For example if I had webpack outputting the following directories
project/css/ <~~~ The plugin helps me eliminate all js files from this directory.
project/js/

@georgetroughton
Copy link

If using the HtmlWebpackPlugin and HtmlWebpackExcludeAssetsPlugin solution above you can use rimraf as part of your build script to delete the files you don't want, something like -

"build": "NODE_ENV=production yarn run clean && webpack -p && rimraf dist/js/style.*.js"

Works for me...

niedzielski added a commit to wikimedia/wikimedia-page-library that referenced this issue Jan 31, 2018
- This initial Webpack refactor patch aims for parity with the previous
  Rollup.js implementation. The configuration was largely derived from
  project Marvin. There are many enhancements possible with the new
  configuration but an effort to keep changes minimal where practical
  was made. For example, subsequent patches may diversify the library
  entry points offered, automatically vendor prefix all CSS, or inline
  image assets as data URIs.

  https://phabricator.wikimedia.org/source/marvin/browse/master/

- The unusual Rollup.js Babel configuration is simplified and
  consolidated at the project root.

- An empty PostCSS configuration is included for later auto-vendor
  prefixing.

- The JavaScript and CSS artifacts have been minimized in production
  builds. Notably, the JavaScript build product is now half what it was.

- A superfluous entry, build/wikimedia-page-library-override.js, is now
  generated and may safely be ignored. This is noted in the readme.

  webpack-contrib/extract-text-webpack-plugin#518

- All demo URLs have been updated to reference webpack-dev-server
  outputs.

- There are no anticipated client changes necessary but integrators
  should smoke test CSS and JavaScript functionality, especially on
  older devices.

- The NPM clean script has been removed as this is part of the build
  process provided by Webpack and the "Clean for WebPack" plugin.

- The build:watch NPM script is preserved to retain existing app
  developer workflows.
niedzielski added a commit to wikimedia/wikimedia-page-library that referenced this issue Jan 31, 2018
- This initial Webpack refactor patch aims for parity with the previous
  Rollup.js implementation. The configuration was largely derived from
  project Marvin. There are many enhancements possible with the new
  configuration but an effort to keep changes minimal where practical
  was made. For example, subsequent patches may diversify the library
  entry points offered, automatically vendor prefix all CSS, or inline
  image assets as data URIs.

  https://phabricator.wikimedia.org/source/marvin/browse/master/

- The unusual Rollup.js Babel configuration is simplified and
  consolidated at the project root.

- An empty PostCSS configuration is included for later auto-vendor
  prefixing.

- The JavaScript and CSS artifacts have been minimized in production
  builds. Notably, the JavaScript build product is now half what it was.

- A superfluous entry, build/wikimedia-page-library-override.js, is now
  generated and may safely be ignored. This is noted in the readme.

  webpack-contrib/extract-text-webpack-plugin#518

- All demo URLs have been updated to reference webpack-dev-server
  outputs.

- There are no anticipated client changes necessary but integrators
  should smoke test CSS and JavaScript functionality, especially on
  older devices.

- The NPM clean script has been removed as this is part of the build
  process provided by Webpack and the "Clean for WebPack" plugin.

- The build:watch NPM script is preserved to retain existing app
  developer workflows. App devs should verify that their processes are
  unaltered.
ravasthi added a commit to ravasthi/css3-foundation that referenced this issue Mar 26, 2018
Why:

Webpack 4 will soon have the ability to handle CSS inputs/outputs natively, but doesn't yet. As a result, when we add our CSS or Sass files as entry points and use the extract text webpack plugin, or the new webpack 4 compatible mini css extract plugin, we'll get bogus, extraneous JS files generated for each of our CSS assets. See [this issue](webpack-contrib/extract-text-webpack-plugin#518) for more details.

This change addresses the need by:

Using the `rimraf` package to remove the unnecessary files after build.
ravasthi added a commit to ravasthi/css3-foundation that referenced this issue May 14, 2018
Why:

Webpack 4 will soon have the ability to handle CSS inputs/outputs natively, but doesn't yet. As a result, when we add our CSS or Sass files as entry points and use the extract text webpack plugin, or the new webpack 4 compatible mini css extract plugin, we'll get bogus, extraneous JS files generated for each of our CSS assets. See [this issue](webpack-contrib/extract-text-webpack-plugin#518) for more details.

This change addresses the need by:

Using the `rimraf` package to remove the unnecessary files after build.
@Legends
Copy link

Legends commented May 22, 2018

Are there plans to support this in the future/milestone?

@Dwood15
Copy link

Dwood15 commented May 23, 2018

I would like to see this as well.

@Legends
Copy link

Legends commented May 23, 2018

Aaaa I see I am in the extract-text-webpack-plugin repo.
Btw. will there be any further support for extract-text-webpack-plugin in wp4/5/... ?

ravasthi added a commit to ravasthi/css3-foundation that referenced this issue May 23, 2018
Why:

Webpack 4 will soon have the ability to handle CSS inputs/outputs natively, but doesn't yet. As a result, when we add our CSS or Sass files as entry points and use the extract text webpack plugin, or the new webpack 4 compatible mini css extract plugin, we'll get bogus, extraneous JS files generated for each of our CSS assets. See [this issue](webpack-contrib/extract-text-webpack-plugin#518) for more details.

This change addresses the need by:

Using the `rimraf` package to remove the unnecessary files after build.
ravasthi added a commit to ravasthi/css3-foundation that referenced this issue May 23, 2018
Why:

Webpack 4 will soon have the ability to handle CSS inputs/outputs natively, but doesn't yet. As a result, when we add our CSS or Sass files as entry points and use the extract text webpack plugin, or the new webpack 4 compatible mini css extract plugin, we'll get bogus, extraneous JS files generated for each of our CSS assets. See [this issue](webpack-contrib/extract-text-webpack-plugin#518) for more details.

This change addresses the need by:

Using the `rimraf` package to remove the unnecessary files after build.
@dgroh
Copy link

dgroh commented Jul 9, 2018

For those who work with mono repo this is an issue, because we don't want to important the styles in every application because it duplicates the css reference, that is why importing the common styles in the entry point is important and relevant IMO...

For example:

module.exports = {
  entry: {
    "assets-app": "./assets-app/src/index.js",
    "pages-app": "./pages-app/src/index.js",
    "styles": ["./common/styles.less", "./common/styles.scss"]
  },

assets-app and pages-app share the same styles...

@fqborges
Copy link

I faced the same issue of having a style only entry (css/sass/less) generating an extra .js file, and ended up creating a webpack plugin to remove the js file from the compilation.

I published it on npm as webpack-fix-style-only-entries. You can find the source code on https://github.com/fqborges/webpack-fix-style-only-entries.

:-) shamelessly promoting my package :-)

@kristofsw
Copy link

@fqborges Your package seems to do the trick!

@mikechabot
Copy link

@fqborges Well done!

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