webpack-shell-plugin
webpack-shell-plugin copied to clipboard
1337programming
Tapable.plugin is deprecated
WebpackShellPlugin is causing a warning with Webpack 4. When I run node --trace-deprecation ./node_modules/.bin/webpackI get this:
(node:83992) DeprecationWarning: Tapable.plugin is deprecated. Use new API on `.hooks` instead
at WebpackShellPlugin.apply (/projectDir/node_modules/webpack-shell-plugin/lib/index.js:236:16)
I would have submitted a PR, but looks like I can't build the project without errors and it doesn't pass linting. In addition, there hasn't been much activity in a year so in case someone else is encountering the same issue, you can fix it locally.
Just replace all compiler.plugin('hookName', ...) calls with compiler.hook.[hookName].tap or compiler.hook.[hookName].tapAsync if it's asynchronous and gets a callback as an argument.
@iSynth you can also try patching it with https://github.com/ds300/patch-package/ while waiting for a proper fix
I fixed this by ditching the plugin and using the new Webpack Plugin API directly from my webpack config:
const exec = require('child_process').exec;
module.exports = {
// ... other config here ...
plugins: [
// ... other plugins here ...
{
apply: (compiler) => {
compiler.hooks.afterEmit.tap('AfterEmitPlugin', (compilation) => {
exec('<path to your post-build script here>', (err, stdout, stderr) => {
if (stdout) process.stdout.write(stdout);
if (stderr) process.stderr.write(stderr);
});
});
}
}
]
};
I was planning to do it, but when I forked the repo, I noticed that it doesn't build without errors etc.
If this repo hasn't had any activity during the last year, I'd say the chances of it getting approved are quite slim.
@tlaak alright, thanks for the reply - went with the solution by @jchook which worked 👍
compiler.hook.[hookName]
FYI Should be compiler.hooks.[hookName] for anyone copy & pasting
instred of using WebpackShellPlugin you can use compiler hooks
const exec = require('child_process').exec;
module.exports = {
// ... other config here ...
plugins: [
// ... other plugins here ...
{
apply: (compiler) => {
compiler.hooks.afterEmit.tap('AfterEmitPlugin', (compilation) => {
exec('<path to your post-build script here>', (err, stdout, stderr) => {
if (stdout) process.stdout.write(stdout);
if (stderr) process.stderr.write(stderr);
});
});
}
}
] };
I've tried the above solution anyone had any difficulty calling nodemon even on a simple script that just calls console. When I do this it just hangs, I try running all the NODE_DEBUG flags and it's like it never gets to even starts looking for modules to execute.
I've tried this from within:
exec('nodemon dist/index.js', () => {});
I even created a bash script to launch it:
exec('./scripts/nodemon.sh', () => {});
If I use just node to launch the script, it's fine but nodemon it just hangs. Even more weirdly, if I again use node with a more complex script (this is TypeScript but is compiled to JS before it runs):
import express from 'express';
import { Request, Response } from 'express';
const app = express();
const { port = 3000 } = process.env;
app.get('/', (req: Request, res: Response) => {
res.send('hello world');
});
// app.listen(port, () => {
// console.log(`server started on ${port}`);
// });
It will work until I remove the comments to start the actual server then it just hangs again.
Tried this on multiple node versions, same issue, any ideas?
@thearegee you should not call long-running processes like nodemon or app.listen() via webpack hooks. If you must, perhaps add & to the end of the command to send it to the background, e.g.
exec('nodemon dist/index.js &', () => {});
Quoting the bash manual:
If a command is terminated by the control operator
&, the shell executes the command in the background in a subshell. The shell does not wait for the command to finish, and the return status is 0. Commands separated by a;are executed sequentially; the shell waits for each command to terminate in turn. The return status is the exit status of the last command executed.
You may prefer to use package.json scripts for your use case.
@jchook but is that not the point of webpack-shell-plugin?
Giving an example, you want to run webpack on your dev server, then when you make a code change to a file, you want to not only be able to trigger webpack transpiling of your files but also a restart of the server so you can see the changes.
However I can understand what you are saying, but the other issue was, if we ignore this part about nodemon. If you run a node script to start a webserver using express as soon as you add this snipit:
app.listen(port, () => {
console.log(`server started on ${port}`);
});
It just hangs and never starts
@thearegee no. For that case, use webpack-dev-server, which supports hotloading changes, etc. Usually I think folks run this on their local dev machine or VM.
webpack-shell-plugin lets you run helper scripts during your build process (for example, if you want a notification every time a build fails or succeeds, or if you want external tools to run during your build). It does not work well as a daemon or server process manager.
If you want to automatically update servers in a remote environment such as staging or production, look into CI/CD (continuous integration / continuous delivery) tools or platforms. You have a lot of options there. Personally I enjoyed using Semaphore CI and GitLab (both have a free tier). You can also roll you own CI with tools like dsh, rsync and xargs.
It just hangs and never starts
I would bet you $10 that it did start. Have you checked to see whether it listened on port?
@jchook it would be hard for me to cash that in but yeah, I would look to see what process would be listening to that port and not see anything ¯_(ツ)_/¯
CI/CD pipelines are not a concern for this project at the moment but thanks for the suggestion.
I will have a play with webpack-dev-server and see if that solves my problem. I was just looking at how people had used webpack-shell-plugin and I saw lots of uses with nodemon and as hooks was suggested as a replacement for the deprecated Tapable.plugin I tried to do the same thing. Guess that was the wrong approach.
When I come up with a solution I will post it here and might help people who have had same issue.
Thank you
Seeing as it is stop not fixed and last response almost a year ago, I wouldn’t think a fix is imminent. I did have the same issue with one of my webpack plugins which I fixed over two years ago. In fact, I recall that I also fixed it in this plugin but only locally? I could fork and fix this one as I am not sure the maintainer of this plugin is fixing issues
Last commits were over 3 years ago so I'd consider this repo very much abandoned.
I found this that seems to be recently updated. https://github.com/s00d/webpack-shell-plugin-next
Looks viable to me. I would just go with that version and call it a day. I have looked back on my edits and I did in fact just edit the source locally for the projects I am using.