We Keep Coding

"TypeError: Invalid value used in weak set" while build using webpack

I'm trying to add scss to the project. I want to build css files from scss ones, but I get an error that says "TypeError: Invalid value used in weak set" since I added MiniCssExtractPlugin.
Here's my webpack.config.js:
const path = require('path');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
const config = {
// TODO: Add common Configuration
module: {},
};
const js = Object.assign({}, config, {
name: 'js',
entry: path.resolve(__dirname, 'index.js'),
output: {
path: path.resolve(__dirname, '../some/path/here'),
filename: 'main.js',
},
});
const scss = Object.assign({}, config, {
name: 'scss',
entry: path.resolve(__dirname, './scss/styles.scss'),
plugins: [
new MiniCssExtractPlugin({
filename: '[name].css',
}),
],
module: {
rules: [
{
test: /\.(s*)css$/,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
{
loader: 'sass-loader',
options: {
implementation: require('sass'),
},
},
],
},
],
},
output: {
path: path.resolve(__dirname, '../some/path/here'),
filename: 'styles.css',
},
});
module.exports = [js, scss];
I googled a lot but didn't find any answers.
I use Node.js v 8.4.0.
Console output (There is more, but I think this is enough):
TypeError: Invalid value used in weak set
at WeakSet.add (native)
at MiniCssExtractPlugin.apply (/path/path/path/path/path/path/path/node_modules/mini-css-extract-plugin/dist/index.js:362:18)
PS: I'm new to webpack, so I'll be glad if you help me to make this code better. The main idea is to keep js compilation the same and add scss compilation. I also want to compile included scss files as separated ones.
PSS: If you need more information, I'll provide some, coz idk what else can be useful.

Maybe the latest mini-css-extract-plugin version has bugs. And I tried to use another version of this package. And its Worked!!!
Remove your last package version:
npm uninstall mini-css-extract-plugin
Download this version 0.9.0 (its worked for me):
npm i --save-dev mini-css-extract-plugin#0.9.0
*optionally (--save-dev)
checkout all versions:
mini-css-extract-plugin/all-versions

This is most likely due to either a bug or an incompatible version of webpack, e.g. upgrading to the current major v2.0.0 releases on webpack 4.
For more information, please check the changelog for breaking changes and fixes.

I think you'll need to downgrade some other plugins as well. I was following a tutorial when I had the same error. This is what worked for me:
{
"name": "recipe-blocks",
"scripts": {
"dev": "cross-env BABEL_ENV=default webpack --watch",
"build": "cross-env BABEL_ENV=default NODE_ENV=production webpack -p"
},
"main": "index.js",
"devDependencies": {
"#babel/core": "^7.0.0",
"#babel/plugin-transform-react-jsx": "^7.2.0",
"#wordpress/babel-preset-default": "^3.0.1",
"babel-loader": "^8.0.4",
"classnames": "^2.2.6",
"cross-env": "^5.1.5",
"css-loader": "^2.1.1",
"mini-css-extract-plugin": "^0.6.0",
"node-sass": "^4.12.0",
"raw-loader": "^2.0.0",
"sass-loader": "^7.1.0",
"webpack": "^4.26.1",
"webpack-cli": "^3.1.2"
},
"version": "1.0.0",
"license": "MIT"
}
Then Run:
npm install
npm run dev

How to create typescript library with webworkers using worker-loader

I try to create typescript library with web workers. When I test my code with webpack-dev-server everything looks good, all files are found, but when I make npm run build and try to use lib in another local project (npm install /local/path), I see GET http://localhost:8080/X.worker.js in browser console.
webpack.config.js:
const path = require('path');
module.exports = {
devtool: 'inline-source-map',
entry: {
'mylib': './src/index.ts',
'mylib.min': './src/index.ts',
},
output: {
path: path.resolve(__dirname, '_bundles'),
filename: '[name].js',
libraryTarget: 'umd',
library: 'mylib',
umdNamedDefine: true
},
resolve: {
extensions: ['.ts', '.tsx', '.js']
},
optimization: {
minimize: true
},
module: {
rules: [
{
test: /\.tsx?$/,
loader: 'awesome-typescript-loader',
exclude: /node_modules/,
query: {
declaration: false,
}
},
{
test: /\.worker\.js$/,
use: {
loader: "worker-loader"
}
},
]
}
};
tsconfig.json
{
"compilerOptions": {
"target": "es5",
"module": "es6",
"lib": [
"webworker",
"es2015",
"dom"
],
"moduleResolution": "node",
"sourceMap": true,
"strict": true,
"alwaysStrict": true,
"outDir": "lib",
"resolveJsonModule": true,
"declaration": true,
"skipLibCheck": true,
"allowJs": true
},
"include": [
"**/*.ts",
"**/*.tsx"
],
"exclude": [
"node_modules",
"lib",
]
}
package.json
{
"name": "mylib",
"version": "1.0.0",
"description": "",
"main": "_bundles/mylib.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"webpack": "webpack",
"build": "rm -rf ./lib && tsc",
"serve": "webpack-dev-server",
"clean": "rm -rf _bundles lib lib-esm",
"newbuild": "npm run clean && tsc && tsc -m es6 --outDir lib-esm && webpack"
},
"repository": {
"type": "git",
"url": "..."
},
"keywords": [],
"author": "",
"license": "ISC",
"bugs": {
"url": "..."
},
"homepage": "...e",
"devDependencies": {
"prettier": "^2.1.2",
"tslint": "^6.1.3",
"tslint-config-prettier": "^1.18.0",
"worker-loader": "^3.0.5"
},
"dependencies": {
...
}
}
Example on how I import workers:
import X from "worker-loader!./X";

I found myself in the exact same situation a few months back. I found a solution that worked for me, but first lets discuss why this is happening.
The problem:
There are 3 layers here.
The development layer of your library
The build layer of your library
The application that consumes the build of your library
Layer 1 is simple. In whatever file you want to create a new worker, say its index.ts, you do your import X from "worker-loader!./X". Your index.ts knows exactly where to find your worker file. That's why things work on your webpack-dev-server.
Layer 2 is where things get weird. When you process the worker file with worker-loader, webpack outputs several files. Your config says filename: '[name].js', which would output a file for every file in your source folder, all on the same level in your _bundles folder. Webpack sees your import X from "worker-loader!./X", and it also sees your target name and location for the imported file, and the file doing the importing. It rewrites the location of the web worker file within the index.js output bundle to an absolute path relative to the rest of the bundle. You can control this more carefully by using the publicPath option in the worker-loader. But this doesn't really solve the issue, as you are only setting the publicPath as an absolute path, which leads us to step 3...
Layer 3, where you try to consume your package, is where things go wrong. You could never anticipate where one might try to import { makeAWorker } from 'your-library' in their code. Regardless of where they import it, the build file (in the consumer app's node_modules) will be using the path that webpack wrote into the build of index.js to look for the worker file, but now the absolute path is relative to your consumer project (usually the home path, like where index.html lives), not to the node_modules folder of the build. So your consumer app has no idea where to find the worker file.
My solution: a bit of a hack
In my scenario, I decided that the content of my worker files was simple enough to create a worker from a string, and import it that way. For example, a worker file looked like this:
// worker.ts
// Build a worker from an anonymous function body
export default URL.createObjectURL(
new Blob([
'(',
function () {
// actual worker content here
}.toString(),
')()', ],
{ type: 'application/javascript' }
)
);
Then in the place where I want to spawn the worker:
// index.ts
import workerScript from './worker';
const myWorker = new Worker(workerScript, {worker_options});
This works because now you are no longer asking webpack to create a file and write the correct import locations for you. In the end, you won't even have separate files in your bundle for your worker scripts. You can ditch worker-loader altogether. Your index.ts will create the Blob and its URL, and your consumer application will find the worker script at that URL which is dynamically generated at runtime.
A hack indeed
This method comes with some serious drawbacks, which led me to ask the question bundle web workers as integral part of npm package with single file webpack output. The issue is that inside your worker script, you really don't have the option to import anything. I was lucky in that my worker was relatively simple. It depended on a single node_module, which itself had no dependencies. I started out by simply including the source of that module in the script, but as I had multiple scripts that needed that same external module, I ended up passing it as a piece of data to the worker when it gets spawned:
import { Rainbow } from './utils';
var data = {
id,
data
RainbowAsString: Rainbow.toString(),
};
myWorker.postMessage(data);
Then within the worker I simply convert RainbowAsString back to a function and use it. If you are curious to see more detail, you can check out the library I built with this method: leaflet-topography. Look into the src/TopoLayer.ts file to see how the workers are used, and the src//workers folder to see how I set up the worker blobs.
Conclusion
I think there must be a better way. One possible quick fix would be to write a copy script that would copy the worker files from node_modules/yourLibrary to the build folder of your consumer app. But this doesn't make for great portability, and other peple are going to have to do the same thing to get your library working with their app. My solution isn't perfect, but it works for simple-ish worker scripts. I am still thinking about a more robust solution that allows workers to do their own imports.
Edit: A proper solution:
So after writing this answer, I was inspired to join the conversation How can I use this to bundle a library? in the webpack-loader repo. Apparently, when webpack 5 was released about 2 months ago, they added support for this syntax:
new Worker(new URL('./path/to/worker.js', import.meta.url))
I have not tried this, but it looks like the solution you need (and the solution I needed 2 months ago when I was coming up with my hack). Try this out - it may be exactly what you need to tell webpack to bundle your library while stil maintaining the relationship between worker script and the script that imports it.

Why does the "exports-loader" example in Webpack's documentation not work?

Webpack provides the example below in its shimming documentation. In the global exports portion of that page, it gives the following example.
webpack.config.js
module.exports = {
module: {
rules: [
{
test: require.resolve('globals.js'),
use: exports-loader?file,parse=helpers.parse
}
]
}
}
./src/globals.js
var file = 'blah.txt';
var helpers = {
test: function() { console.log('test something'); },
parse: function() { console.log('parse something'); }
};
But when I attempt to build, I get:
ERROR in ./webpack.config.js
Module not found: Error: Can't resolve 'globals.js' in '/workspace/my-app'
Why is globals.js not resolving, and why does the example in their documentation assume it will? Am I missing something? Thanks.

Getting this to work with a global exports-loader configuration
I have this working with the following setup:
src/deps.js // this file just declare a global file variable
const file = 'this is the file';
src/app.js // entry point of the webpack bundle. It import's deps.js (even if deps.js does not have an export statement, thanks to export-loader):
import file from './deps.js'
console.log(file);
webpack.config.js // webpack configuration file
module.exports = {
entry: __dirname + '/src/app.js',
mode: 'development',
module: {
rules: [
{
test: /deps.js/,
use: 'exports-loader?file',
}
]
}
}
package.json // so we can run webpack locally to the project
{
"name": "exports-loader-test",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"webpack": "node_modules/webpack/bin/webpack.js"
},
"author": "",
"license": "ISC",
"devDependencies": {
"exports-loader": "^0.7.0",
"webpack": "^4.29.6",
"webpack-cli": "^3.2.3"
}
}
With this setup, assuming webpack.config.js, package.json and src/ are in the root of the project, do:
$ npm run webpack
To bundle the scripts, then:
$ node dist/main.js to check that the file variable is being loaded (to load this in a browser will do the same).
 Getting this to work with an import specific configuration.
(this comes from this other answer).
In order to do so, you need to use just the exports-loader, without any further configuration when you load it in the webpack.config.js:
use: 'exports-loader',
And then specify the variables to wrap in an export clause in every import statement:
import file from 'exports-loader?file!./deps.js'
Why the require.resolve() syntax is not working?
I really don't know. The test clause expects a regex as far as I know (that's why it is called test in fact, because of the test method of regex's in javascript) and I'm not used to other kind of valid syntaxes. I see that in your snippet:
module.exports = {
module: {
rules: [
{
test: require.resolve('globals.js'),
use: exports-loader?file,parse=helpers.parse
}
]
}
}
The use value does not have string quotes. I wonder if this is broking the config and then you get a misleading error, I don't know. I actually believe you just didn't paste the quotes when copy and pasting to stack overflow.

Newbie GET error on Webpack, used for http server and bundling

Okay so I'm a designer learning to code. This is probably a pretty simple issue but I'm stuck and I've been banging my head against the wall for hours trying to figure this out.
I'm following this tutorial here:
https://www.smashingmagazine.com/2017/02/a-detailed-introduction-to-webpack/
It has a repo that goes along with it here: https://github.com/joezimjs/Webpack-Introduction-Tutorial
I had a bunch of problems at the beginning because "./dist" was not considered a valid path, because relative paths were banned by webpack or something. Changed it to "/dist" and that fixed stuff, but then I ran into problems with the babel loader trying to process the node modules, so I put exclude node modules. That was something in the code on the repo but not in the tutorial so it took me some digging.
I've gotten to example five in the tutorial and I'm trying to run the server so that it creates the html page, but it's not working. I've tried copying and pasting all the original code, but it won't work. The server runs, but when I visit the localhost:8080 it gets a 404 error from the GET / ( which I guess basically means whatever path it's supposed to be getting via http methods isn't working?)
Here's a link to my repo:
https://github.com/thedonquixotic/webpack-practice
Here's my config.json file:
{
"name": "webpack-practice",
"version": "1.0.0",
"description": "project to practice webpack",
"main": "index.js",
"scripts": {
"prebuild": "del-cli dist -f",
"build": "webpack",
"server": "http-server ./dist",
"start": "npm run build -s && npm run server -s"
},
"author": "David Aslan French",
"license": "ISC",
"devDependencies": {
"babel-core": "^6.26.3",
"babel-loader": "^7.1.4",
"babel-plugin-transform-runtime": "^6.23.0",
"babel-polyfill": "^6.26.0",
"babel-preset-es2015": "^6.24.1",
"del-cli": "^1.1.0",
"handlebars": "^4.0.11",
"handlebars-loader": "^1.7.0",
"html-webpack-plugin": "^3.2.0",
"http-server": "^0.11.1",
"webpack": "^4.12.0",
"webpack-cli": "^3.0.8"
},
"dependencies": {
"lodash": "^4.17.10"
}
}
Here's my webpack.config.js file:
var HtmlWebpackPlugin = require('html-webpack-plugin');
module.exports = {
entry: [
'babel-polyfill',
'./src/main.js'
],
output: {
path: '/dist',
filename: 'bundle.js'
},
module: {
rules: [
{
test: /\.jsx?$/, loader: 'babel-loader', exclude: /node_modules/,
options: { plugins: ['transform-runtime'], presets: ['es2015'] }
},
{ test: /\.hbs$/, loader: 'handlebars-loader', exclude: /node_modules/ }
]
},
plugins: [
new HtmlWebpackPlugin({
title: 'Intro to Webpack',
template: 'src/index.html'
})
]
};
Sooooo... yeah... I'm burnt out and I can't figure out what I'm doing wrong.

YES!!!! I figured it out!
So here's the deal. It's a bunch of little things adding up.
The core of the problem is that the repo uses webpack 2 but when I npm install webpack it is webpack 4. Webpack 4 requires webpack-cli and webpack-cli doesn't allow for relative paths. So if I change the webpack.config.js file to an absolute path it doesn't create a new folder. And with no folder, there's no way to load the bundled files so it fails the GET the necessary code.
In order to have the correct path I need to use the dirname AND also include the const path =require ('path') solution. Which I just realized #ippi already suggested, and while I had tried the dirname change, I didn't define the const. I'm still really new to Javascript so stuff like that doesn't really occur to me.
Lastly it threw an error for index.html which was just a matter of me needing to add /node_modules/ to the exclude settings for babel. AWESOME! It works!!!!!

Node.js + Typescript + Webpack = Module not found

I'm new with Webpack, Node.js and Typescript and I'm having trouble configuring my dev enviroment.
When running webpack to compile my src/server.ts to generate the /server/bundle.js I'm getting this error:
ERROR in ./src/server.ts
Module not found: Error: Can't resolve 'hapi' in '/Volumes/Dados/giovane/dev/studio-hikari/nodang/nodang-api/src'
# ./src/server.ts 3:11-26
The architecture of the project is:
The src/server.ts:
import * as Hapi from 'hapi';
const server = new Hapi.Server();
The webpack.config.js:
const path = require('path');
module.exports = {
entry: './src/server.ts',
output: {
filename: './server/bundle.js'
},
resolve: {
extensions: ['.ts'],
modules: [
path.resolve('src'),
path.resolve('node_modules')
]
},
module: {
loaders: [
{
test: /.ts$/,
loader: 'awesome-typescript-loader'
}
]
}
};
The package.json:
{
"name": "nodang-api",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"compile": "webpack --progress --watch",
"serve": "node-dev server/bundle.js"
},
"author": "",
"license": "ISC",
"dependencies": {
"#types/hapi": "^16.0.0",
"lodash": "^4.17.4"
},
"devDependencies": {
"awesome-typescript-loader": "^3.0.8",
"tsd": "^0.6.5",
"typescript": "^2.2.1",
"webpack": "^2.2.1"
}
}
OBS: It's webpack 2
UPDATE
After installing hapi and adding .js to webpack's resolve extentions and node as webpack's target I'm getting this erros with hapi modules:
ERROR in ./~/hapi/lib/server.js
Module not found: Error: Can't resolve 'catbox' in '/Volumes/Dados/giovane/dev/studio-hikari/nodang/nodang-api/node_modules/hapi/lib'
# ./~/hapi/lib/server.js 5:15-32
# ./~/hapi/lib/index.js
# ./src/server.ts
ERROR in ./~/hapi/lib/server.js
Module not found: Error: Can't resolve 'catbox-memory' in '/Volumes/Dados/giovane/dev/studio-hikari/nodang/nodang-api/node_modules/hapi/lib'
# ./~/hapi/lib/server.js 6:21-45
# ./~/hapi/lib/index.js
# ./src/server.ts

You did not install hapi. #types/hapi are just the type definitions that TypeScript uses for the library, but not the actual library itself. So you need to add hapi as well:
npm install --save hapi
Once you've installed it, the module can be found, although you'll get a new error that ./server could not be resolved in hapi/lib/index.js and that's because you configure resolve.extensions to only include .ts, but the library makes use of Node automatically resolving .js when leaving off the extension. So you also need to include .js in the extensions:
extensions: ['.ts', '.js'],
After also resolving this issue, you'll be faced with another one, namely that Node built-in modules like fs can't be resolved. By default webpack builds for the web, so the Node built-in modules are not available. But you can change that by setting the target option in your webpack config to node:
target: 'node'
Edit
You're having trouble with other node_modules because you only use the top level node_modules, instead you want to always fall back to the regular module resolution of node_modules, so the resolve.modules should look like this:
modules: [
path.resolve('src'),
'node_modules'
]