GithubHelp home page GithubHelp logo

merkle-open / webpack-config-plugins Goto Github PK

View Code? Open in Web Editor NEW
644.0 24.0 38.0 14.23 MB

Provide best practices for webpack 4 loader configurations

Home Page: https://webpack-config-plugins.js.org/

License: MIT License

JavaScript 80.99% TypeScript 18.72% HTML 0.28%
webpack config plugins webpack-plugin

webpack-config-plugins's Introduction





NPM version Build Status lerna

License Commitizen friendly Prettier

Pluggable webpack configurations

Creating webpack loader configurations can be quite time consuming.
This project tries to provide best practices for the most common loader requirements: ts, js, scss, fonts and images.

Instead of copying loader configs from github and stackoverflow you could just add one of the following plugins.



Required Webpack Version

The compatible version of webpack to each plugin may vary and is documented in each package.json file under the peerDependencies property.

Quick overview

npx generate-webpack-config

Alternatively you can also use the online config tool to get started.

Zero Config example

Webpack itself provides many defaults so you are able to run the common-config-webpack-plugin without a webpack.config file:

npm i --save-dev webpack webpack-cli common-config-webpack-plugin

npx webpack --plugin common-config-webpack-plugin

Demo

Zero Config webpack-dev-server example

You can even setup an entire development server without configuration:

npm i --save-dev webpack common-config-webpack-plugin html-webpack-plugin

webpack-dev-server --plugin common-config-webpack-plugin --plugin html-webpack-plugin

Demo

Webpack Config

Many projects will need some project specific options. The common-config-webpack-plugin suite is designed to be plugable so you will be able to pick only what you need and combine it with your configuration. By default the plugin configuration will adjust depending on your webpack mode setting.

common-config-webpack-plugin
  ├── js-config-webpack-plugin
  ├── ts-config-webpack-plugin
  ├── scss-config-webpack-plugin
  └── asset-config-webpack-plugin
      ├── font-config-webpack-plugin
      └── image-config-webpack-plugin

Use them all

To get started you can just add all common-config-webpack-plugin parts at once.

const CommonConfigWebpackPlugin = require('common-config-webpack-plugin');

module.exports = {
  plugins: [new CommonConfigWebpackPlugin()],
};

Which would be exactly the same as

const JsConfigWebpackPlugin = require('js-config-webpack-plugin');
const TsConfigWebpackPlugin = require('ts-config-webpack-plugin');
const ScssConfigWebpackPlugin = require('scss-config-webpack-plugin');
const FontConfigWebpackPlugin = require('font-config-webpack-plugin');
const ImageConfigWebpackPlugin = require('image-config-webpack-plugin');

module.exports = {
  plugins: [
    new JsConfigWebpackPlugin(),
    new TsConfigWebpackPlugin(),
    new ScssConfigWebpackPlugin(),
    new FontConfigWebpackPlugin(),
    new ImageConfigWebpackPlugin(),
  ],
};

Use only javascript (.js & .jsx & .mjs)

NPM version Build Status

🗒️js-config-webpack-plugin Readme
⚙️development webpack.config.js
⚙️production webpack.config.js

The js-config-webpack-plugin is a modified version of the create-react-app best practices.
By default the plugin configuration will adjust depending on your webpack mode setting.

const JsConfigWebpackPlugin = require('js-config-webpack-plugin');
module.exports = {
  plugins: [new JsConfigWebpackPlugin()],
};

Use only typescript (.ts & .tsx)

NPM version Build Status

🗒️ts-config-webpack-plugin Readme
⚙️development webpack.config.js
⚙️production webpack.config.js

The ts-config-webpack-plugin is a modified version of the ts-loader best practices.
By default the plugin configuration will adjust depending on your webpack mode setting.

const TsConfigWebpackPlugin = require('ts-config-webpack-plugin');
module.exports = {
  plugins: [new TsConfigWebpackPlugin()],
};

Use only styles (.css & .scss)

NPM version Build Status

🗒️scss-config-webpack-plugin Readme
⚙️development webpack.config.js
⚙️production webpack.config.js

The scss-config-webpack-plugin is a modified version of the create-react-app best practices.
By default the plugin configuration will adjust depending on your webpack mode setting.

const ScssConfigWebpackPlugin = require('scss-config-webpack-plugin');
module.exports = {
  plugins: [new ScssConfigWebpackPlugin()],
};

Use only assets (Font & Images)

NPM version Build Status

🗒️asset-config-webpack-plugin Readme

The asset-config-webpack-plugin is just a wrapper around the font-config-webpack-plugin and the image-config-webpack-plugin.

const AssetConfigWebpackPlugin = require('asset-config-webpack-plugin');
module.exports = {
  plugins: [new AssetConfigWebpackPlugin()],
};

Use only fonts (.woff & .woff2)

NPM version Build Status

🗒️font-config-webpack-plugin Readme
⚙️development webpack.config.js
⚙️production webpack.config.js

The font-config-webpack-plugin will allow you to use woff-fonts.

const FontConfigWebpackPlugin = require('font-config-webpack-plugin');
module.exports = {
  plugins: [new FontConfigWebpackPlugin()],
};

Use only images (.gif & .jpg & .jpeg & .png & .svg)

NPM version Build Status

🗒️image-config-webpack-plugin Readme
⚙️development webpack.config.js
⚙️production webpack.config.js

The image-config-webpack-plugin will allow you to use images from within js and css files.

const ImageConfigWebpackPlugin = require('image-config-webpack-plugin');
module.exports = {
  plugins: [new ImageConfigWebpackPlugin()],
};

Quality checks

The common-config-webpack-plugin suite provides typechecks and integration tests for the loader configurations for Windows and Unix.

Peer dependencies

The common-config-webpack-plugin has a direct dependencies to babel and ts.
However if you need to pick a specific version you can use the js-config-webpack-plugin or ts-config-webpack-plugin which use peer-dependencies instead.

License

The common-config-webpack-plugin is MIT licensed.

webpack-config-plugins's People

Contributors

bencoveney avatar danielruf avatar ernscht avatar janbiasi avatar jantimon avatar johnnyreilly avatar nemchik avatar oliverdietsche avatar smollweide avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

webpack-config-plugins's Issues

image-config-webpack-plugin: Add minifier for production build

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

Images always stay untouched, also in production build.

Expected behavior

Images for production could be minified.

What is the motivation / use case for changing the behavior?

Lossless minificaton of images would reduce the production build size.
We coud take over the webpack config from Nitro to the image-config-webpack-plugin. It uses the img-loader with some imagemin plugins in a pre phase of the url-loader.
This config would make sense for the production build and works perfect ;-)

What do you think?

Improve performance of js-config-webpack-plugin

I'm submitting a...


[x] Performance improvement

Current & Expected behavior

Without the thread-loader, compilation takes three to four times less time on changes. We could remove it.

What is the motivation / use case for changing the behavior?

At least in the nitro example it works much faster without the thread-loader.

The "thread-loader" could be useful for a lot of files or with a different configuration (prewarming). Maybe even a configuration option makes sense?

Support Webpack v5

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

Does not work with webpack 5

Expected behavior

Work with webpack 5

Minimal reproduction of the problem with instructions

Create a webpack 5 project

What is the motivation / use case for changing the behavior?

Improving webpack

I'm going to fill this out properly

Webpack resolve extension not working for the TS Plugin

I'm submitting a...


[ ] Regression (a behaviour that used to work and stopped working in a new release)
[x] Bug report
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behaviour

If you have a project (Nitro for example) and you enable typescript, resolving of the imports do not work.

Example Error, which happens for all imports:

ERROR in ./src/patterns/atoms/image/js/image.ts
Module not found: Error: Can't resolve 'lazysizes/plugins/respimg/ls.respimg' in '/Users/jawidmer/projects/test/src/patterns/atoms/image/js'

Manually setting the extensions in your webpack config fixes the problem:

webpackConfig.resolve.extensions = ['.ts', '.tsx', '.js', '.jsx', '.json', '.d.ts'];

Expected behaviour

Resolving the imports works out of the box, as the extensions for ts get defined here https://github.com/namics/webpack-config-plugins/blob/master/packages/ts-config-webpack-plugin/src/TsConfigWebpackPlugin.js#L73

Minimal reproduction of the problem with instructions

  1. Create new (nitro) project
  2. Enable typescript
  3. Start Server

Environment


Plugin version: 1.3.1
 
- Node version: 10.15.3
- Platform:  Mac

Upgrade clean-webpack-plugin

I'm submitting a...


[ x ] Regression (a behavior that used to work and stopped working in a new release)
[ x ] Bug report  
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

By using the frontend-defaults I end up with the latest version of clean-webpack-plugin with an old setup.

Expected behavior

Setup should work out-of-the-box without any errors.

Minimal reproduction of the problem with instructions

create project by using: npx @namics/frontend-defaults-cli my-project
Start project with npm start

What is the motivation / use case for changing the behavior?

Environment


Plugin version: 1.4.0 
- Node version: 10.16.0
- Platform:  Mac

Contributing Guidelines and devDependencies

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[ ] Feature request
[x] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

When looking into how to contribute to this repo there is a lack of information about tooling.

Expected behavior

https://github.com/namics/webpack-config-plugins/tree/master/.github/CONTRIBUTING.md file that would explain the globally installed tools and processes for contributing to this repository. It would also be great if the devDependencies could include these tools so that installing them globally is not required at all. An example would be
https://github.com/namics/webpack-config-plugins/blob/6bf7421bf492dba2d1b62e1889c3970c2f48b4bf/package.json#L15
using git-cz

Minimal reproduction of the problem with instructions

Clone the repository to a system with no globally installed npm packages. Put the repository in front of a new developer who is unfamiliar with the practices of the current developers and past contributors.

What is the motivation / use case for changing the behavior?

I would personally like to contribute to this repository, and in general having a contributing guideline and including devDependencies for all used tooling prevents the need for globally installing tools that are expected to be used while contributing.

Environment

Removed as irrelevant.

The js-config-webpack-plugin does not work with @babel/core 7.8.4

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

The js-config-webpack-plugin does not work with @babel/core 7.8.4 but works with 7.2.2 as specified in devDependencies.

If using a newer version of @babel/core the following stack trace is thrown:

TypeError: Cannot read property 'push' of undefined
    at JsConfigWebpackPlugin.resolveBabelConfigFilePath (/home/anthon/development/test-webpack-stuff/test-lib/node_modules/js-config-webpack-plugin/src/JsConfigWebpackPlugin.js:36:27)
    at JsConfigWebpackPlugin.apply (/home/anthon/development/test-webpack-stuff/test-lib/node_modules/js-config-webpack-plugin/src/JsConfigWebpackPlugin.js:67:10)
    at webpack (/home/anthon/development/test-webpack-stuff/test-lib/node_modules/webpack/lib/webpack.js:51:13)
    at processOptions (/home/anthon/development/test-webpack-stuff/test-lib/node_modules/webpack-cli/bin/cli.js:272:16)
    at yargs.parse (/home/anthon/development/test-webpack-stuff/test-lib/node_modules/webpack-cli/bin/cli.js:364:3)
    at Object.parse (/home/anthon/development/test-webpack-stuff/test-lib/node_modules/yargs/yargs.js:567:18)
    at /home/anthon/development/test-webpack-stuff/test-lib/node_modules/webpack-cli/bin/cli.js:49:8
    at Object.<anonymous> (/home/anthon/development/test-webpack-stuff/test-lib/node_modules/webpack-cli/bin/cli.js:366:3)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
    at Function.Module._load (internal/modules/cjs/loader.js:585:3)
    at Module.require (internal/modules/cjs/loader.js:692:17)
    at require (internal/modules/cjs/helpers.js:25:18)
    at Object.<anonymous> (/home/anthon/development/test-webpack-stuff/test-lib/node_modules/webpack/bin/webpack.js:156:2)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
    at Function.Module._load (internal/modules/cjs/loader.js:585:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:831:12)
    at startup (internal/bootstrap/node.js:283:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:623:3)

Looking into @babel/core it seems like the findPackageData function was rewritten as a generator function in the following commit 282f81bd676d09c1d8c48b08a7254b961eb41bed. This is probably why the plugin does not work with a later version of @babel/core.

Expected behavior

The plugin should work within the range that is specified for the peerDependencies requirement.

Minimal reproduction of the problem with instructions

Create a new npm project

npm init -y

Install dependencies

npm install --save-dev webpack webpack-cli @babel/core @babel/preset-env @babel/preset-react js-config-webpack-plugin

Create webpack.config.js

# webpack.config.js
const JsConfigWebpackPlugin = require('js-config-webpack-plugin');

module.exports = {
  mode: 'development',
  entry: './src/index.js',
  plugins: [new JsConfigWebpackPlugin()],
}

Create src/index.js

/**
 * @param {string} name - the name to say hello to
 */
export function hello(name = 'anon') {
  console.log('hello ' + name);
}

Build with webpack

npx webpack

Stack trace should be thrown.

What is the motivation / use case for changing the behavior?

Environment


Plugin version: 1.4.0

 
- Node version: v10.18.1  
- Platform: Windows, Ubuntu Subsystem 

Others:

Warning 'missing babel configuration' even if .babelrc exist

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

webpack.config.js

const CleanWebpackPlugin = require('clean-webpack-plugin');
const CommonConfigWebpackPlugin = require('common-config-webpack-plugin');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  plugins: [
    // Cleans the dist folder before the build starts
    new CleanWebpackPlugin(['dist']),
    // Multi threading babel loader configuration with caching for .js and .jsx files
    // Multi threading typescript loader configuration with caching for .ts and .tsx files
    // SCSS Configuration for .css .module.css and .scss .module.scss files
    // File loader configuration for .woff and .woff2 files
    // File loader configuration for .gif .jpg .jpeg .png and .svg files
    // https://github.com/namics/webpack-config-plugins/
    new CommonConfigWebpackPlugin(),
    // Generate a base html file and injects all generated css and js files
    new HtmlWebpackPlugin(),
  ],
};

.babelrc

module.exports = {
  presets: [
    [
      require.resolve('@babel/preset-env'),
      {
        useBuiltIns: 'entry'
      },
    ]
  ],
};

Prints warning:

Couldn't find an appropriate babel configuration file in the current directory.
			Please check if the name of the file is correct and if it's in the correct directory.
			For further information please check the documentation: https://babeljs.io/docs/en/babelrc.html

Expected behavior

.babelrc detected and used

Minimal reproduction of the problem with instructions

execute the following in a new directory:

npx @namics/frontend-defaults-cli@alpha --presetTs

and afterwards:

npm start

Environment


common-config-webpack-plugin version: 1.2.1
clean-webpack-plugin version: 1.0.0
html-webpack-plugin version: 3.2.0

- Node version: 8.10.0
- Platform:  Mac

ts-config-webpack-plugin does not respect browserslist

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

TypeScript compilation is currently limited to the target option by tsconfig.json

Expected behavior

I'd like to compile TypeScript with the target: "esnext" option and let babel do the rest (or compile it completely with babel and only use the fork checker to do the type checking).

What is the motivation / use case for changing the behavior?

The JavaScript plugin is properly respecting the browserslist settings while the TypeScript plugin is not.

Remove .d.ts extension from the TS Plugin

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

If you have a project (Nitro for example) with Babel and no TypeScript files it will include the d.ts files in the build cycle which fails because d.ts files are not compilable whether by the ts-loader nor the fork plugin. We already tested out that if we remove the .d.ts in the resolver extensions everything works as expected (also detecting typing issues in Gondel for example).

Described line is in https://github.com/namics/webpack-config-plugins/blob/master/packages/ts-config-webpack-plugin/src/TsConfigWebpackPlugin.js#L71

Expected behavior

It should not throw an error in case of d.ts imports.

Minimal reproduction of the problem with instructions

  1. Check out the latest Nitro version
  2. Install Gondel
  3. Enable TS in the config
  4. Watch the build fail (even if no TS files provided)

Environment


Plugin version: *

 
- Node version: 8  
- Platform:  Mac & Windows 

Others:

Use sass instead of node-sass in scss-config-webpack-plugin


[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Support request

Current behavior

sass-loader highly recommend using Dart Sass because of performance, limited feature support, ...

Expected behavior

Switch to dart-sass

defaultRules

Would it be possible to use defaultRules instead of rules?

Use new watch API in fork-ts-checker-webpack-plugin

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

Fine

Expected behavior

Could be faster.

Minimal reproduction of the problem with instructions

N/A

What is the motivation / use case for changing the behavior?

Faster builds

Environment

Others:

This isn't a bug report - more a heads up. There's a new feature been added to the fork-ts-checker-webpack-plugin. This feature speeds up incremental compilation.

More details can be found here:

https://blog.johnnyreilly.com/2019/01/typescript-and-webpack-watch-it.html

Would you consider upgrading to this for the performance improvement?

See also: TypeStrong/fork-ts-checker-webpack-plugin#198
And: TypeStrong/fork-ts-checker-webpack-plugin#196

cc @jantimon

JS.ORG CLEANUP

JS.ORG CLEANUP

Hello, it seems a js.org subdomain that was requested to target this repository no longer works.
The subdomain requested was webpack-config-plugins.js.org.js.org and had the target of namics.github.io/webpack-config-plugins.
It produced the following failures when tested as part of the cleanup:

  • HTTP: Failed during request with error 'FetchError: request to http://webpack-config-plugins.js.org.js.org/ failed, reason: getaddrinfo ENOTFOUND webpack-config-plugins.js.org.js.org'
  • HTTPS: Failed during request with error 'FetchError: request to https://webpack-config-plugins.js.org.js.org/ failed, reason: getaddrinfo ENOTFOUND webpack-config-plugins.js.org.js.org'

To keep the js.org subdomain you should add a page with reasonable content within a month so the subdomain passes the validation.
Failure to rectify the issues will result in the requested subdomain being removed from JS.ORGs DNS and the list of active subdomains.

If you are wanting to keep the js.org subdomain and have added reasonable content, YOU MUST reply to the main cleanup issue with the response format detailed at the top to keep the requested subdomain.

🤖 Beep boop. I am a robot and performed this action automatically as part of the js.org cleanup process. If you have an issue, please contact the js.org maintainers.

Warnings/errors when following steps in README.md

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[x] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

Hi. Just wanted to say thanks for the awesome project idea. I found this from the html-webpack-plugin README and love the idea of being able to get a webpack build going without any initial set-up work.

There are warnings/errors when following the installation steps in README.md:

  • tsconfig.json is missing.
  • Incorrect settings in tsconfig.json when instantiating one with tsc --init
  • A missing babel configuration file.
  • Mode is not passed as a CLI arg.
  • src/index.ts file is required - this is shown in the .gif but not stated anywhere else.

I have taken some steps to get an initial working build but I don't know about babel, so will be looking into how to set that up.

Expected behavior

Following the installation steps in the README.md gives a webpack build with no warnings/errors.

Minimal reproduction of the problem with instructions

npm init
npm i --save-dev webpack webpack-cli common-config-webpack-plugin
webpack --plugin common-config-webpack-plugin

This gives the following:

Couldn't find a tsconfig.json in the current working directory.
You can either set the configFile path explicitly or create a new config:
  npx tsc --init
Couldn't find an appropriate babel configuration file in the current directory.
                        Please check if the name of the file is correct and if it's in the correct directory.
                        For further information please check the documentation: https://babeljs.io/docs/en/babelrc.html
Starting type checking service...
Using 1 worker with 2048MB memory limit

Insufficient number of arguments or no entry found.
Alternatively, run 'webpack(-cli) --help' for usage info.

Hash: 128e7870f1d9614d6dd9
Version: webpack 4.28.4
Time: 114ms
Built at: 2019-01-16 20:37:32

WARNING in configuration
The 'mode' option has not been set, webpack will fallback to 'production' for this value. Set 'mode' option to 'development' or 'production' to enable defaults for each environment.
You can also set it to 'none' to disable any default behavior. Learn more: https://webpack.js.org/concepts/mode/

ERROR in Entry module not found: Error: Can't resolve './src' in 'G:\Code\webpack-config-plugins'

Okay, so I am missing:

  • An entry point
  • A typescript config file
  • A babel config file

As mentioned, i haven't looked into babel yet. If I create a src/index.ts run tsc --init (assuming I have a global tsc) I get some additional warnings:

ts-config-webpack-plugin found 2 warnings in "G:/Code/webpack-config-plugins/tsconfig.json".
Warning:
   skipLibCheck option was NOT specified
   By default the fork-ts-checker-webpack-plugin will check all types inside the node_modules directory
   even for unused dependencies and slow down the type checking a lot.
   To skip that checking add the following line to your tsconfig.json compilerOptions configuration:
   "skipLibCheck": true
   To keep the default behaviour with possible performance penalties set skipLibCheck to false to hide this warning.


Warning:
   moduleResolution option was NOT specified
   This will result in typescript warnings like "module not found".
   To fix that add the following line to your tsconfig.json compilerOptions configuration:
   "moduleResolution": "node"
   To keep the default behaviour with possible type checking errors set moduleResolution to "classic" to hide this warning.

What is the motivation / use case for changing the behavior?

As someone who has dived straight into the installation steps (like other new users will likely do) the presence of warnings and errors makes me assume that something has gone wrong, and I am now going on a journey figuring out what else to add.

I have some experience with typescript/webpack so I will be happy to help with some PRs if you think this should be addressed.

I suggest either of the following:

  • Add steps to the README.md that specify how to create the required files.
  • Update webpack-config-plugins to use defaults in the absence of the config files.

The warnings when using the initialised tsconfig.json suggest that actually there are some values that it expects by default to work correctly?

Perhaps there could be some way to instantiate the files if they are not found?

Environment


- Plugin version: 1.2.1
- Node version: v10.1.0
- Platform: Windows 10

js-config-webpack-plugin doesn't export anything

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[X] Bug report  
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

$ node
> require('js-config-webpack-plugin')
{}

Expected behavior

It should expose the plugin.

Minimal reproduction of the problem with instructions

See above.

What is the motivation / use case for changing the behavior?

I want to use the plugin.

Environment


Plugin version: 0.0.1

 
- Node version: 8.11.2  
- Platform: Mac

Make option for exclude in js config

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

https://github.com/namics/webpack-config-plugins/blob/6bf7421bf492dba2d1b62e1889c3970c2f48b4bf/packages/js-config-webpack-plugin/config/production.config.js#L13 and https://github.com/namics/webpack-config-plugins/blob/6bf7421bf492dba2d1b62e1889c3970c2f48b4bf/packages/js-config-webpack-plugin/config/development.config.js#L12 cause the node_modules folder NOT to be processed by the babel loader, and thus code from node packages is not transpiled per my babel configuration.

Expected behavior

It would be great if this could be setup as an option, along the lines of options.jsConfigExclude with a default value of [/[/\\\\]node_modules[/\\\\]/] that could be passed in as

new CommonConfigWebpackPlugin({ jsConfigExclude: "" }),

or

new JsConfigWebpackPlugin({ jsConfigExclude: "" }),

for those of us who want to intentionally include the node_modules folder to be transpiled by babel.

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Using https://www.npmjs.com/package/signature_pad in some of my projects with the common config ends up with class in my bundles, and IE 11 does not know what to do with this, which causes all kinds of problems (the rest of the code in the bundle stops functioning). When including my own override for this by doing:

  module: {
    rules: [
      {
        test: /\.(js|jsx|mjs)$/,
        //exclude: [/[/\\\\]node_modules[/\\\\]/], // exclude node_modules folder per default
        use: [
          // run process in multiple threads
          require.resolve("thread-loader"),
          {
            loader: require.resolve("babel-loader"),
            options: {
              extends: "./.babelrc.json",
              // cache builds, future builds attempt to read from cache to avoid needing to run expensive babel processings
              cacheDirectory: true,
              // do not include superfluous whitespace characters and line terminators
              // https://babeljs.io/docs/en/babel-core/#options
              compact: true,
            },
          },
        ],
      },
    ],
  },

everything is transpiled through babel and works as expected. On my system (which is 6+ years old, dell optiplex 3010, core i3) I did not notice any significant difference in runtime for building bundles. Others may have different experience with that (noting that excluding node_modules is recommended to decrease runtime), which is why I'm hoping this can be an option and the default can maintain the current value so it would not be a breaking change.

Environment


Plugin version: 2.0.1

 
- Node version: v15.5.0 
- Platform:  Windows

Others:

Plugins work only with webpack v4.x

It is not clear that the plugins currently only work with webpack v4.x
We should document this with right compatibility ranges in peerDependencies

Plugin version: 2.0.2

(The webpack 5 update is discussed here: #68)

tslint support for the ts plugin?

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

The ts plugin does not support tslint; the underlying fork-ts-checker-webpack-plugin supports this so it would be nice to use it.

Expected behavior

If there is a tslint.json file in the root of the directory structure; then tslint functionality is switched on.

What is the motivation / use case for changing the behavior?

tslint is useful!

Issue with npx / node and resolve in config file

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

When I have outputPath: path.resolve(_dirname, './dist'), in the config template webpack creates the files in the plugin config dir instead of in the project.

outputPath: path.resolve(process.cwd(), './dist'), seems to solve this.

Not sure if I am doing something wrong or if it is a bug in the used loader.
I use image-webp-loader and the following config:

module: {
		rules: [{
			test: /\.(png|jpe?g)$/i,
			use: [{
				loader: require.resolve('image-webp-loader'),
				options: {
					publicPath: '/',
					outputPath: path.resolve(_dirname, './dist'),
					name: 'images/[name].[hash].[ext]',
					requestWebp: true
				}
			}],
		}, ]
	},

And I use the following command for local testing:
npx webpack --plugin ../../ue-webpack-config-plugins/packages/webp-config-webpack-plugin

Expected behavior

The webp file should be in the project directory not in the plugin config directory.

Minimal reproduction of the problem with instructions

Fork https://github.com/DanielRuf/ue-webpack-config-plugins/ and use the webp-config-webpack-plugin branch.

What is the motivation / use case for changing the behavior?

Environment


Plugin version: X.Y.Z

 
- Node version: 10.12.0  
- Platform: Windows 

Others:

scoop and nvm as package managers.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.