dividab / tsconfig-paths-webpack-plugin

Load modules according to tsconfig paths in webpack.
MIT License
596 stars 51 forks source link

Error on loading plugin in next.js #74

Open amir-arad opened 3 years ago

amir-arad commented 3 years ago

I'm trying to use this plugin (@3.3.0) in next.js (@10) and I get the following error:

(node:63033) UnhandledPromiseRejectionWarning: TypeError: chalk.Instance is not a constructor
    at new TsconfigPathsPlugin (/.../node_modules/tsconfig-paths-webpack-plugin/lib/plugin.js:17:47)
    at Object.webpack (/.../ui/next.config.js:14:29)
    at getBaseWebpackConfig (/.../node_modules/next/build/webpack-config.ts:1293:28)
    at async Promise.all (index 0)
    at HotReloader.start (/.../node_modules/next/server/hot-reloader.ts:304:21)
    at DevServer.prepare (/.../node_modules/next/server/next-dev-server.ts:288:5)
    at Object.openNextServer (/.../server/src/bootstrap.ts:16:5)
    at bootstrap (/.../server/src/main.ts:10:21)

This is my next.config.js:

const TsconfigPathsPlugin = require('tsconfig-paths-webpack-plugin');
const path = require('path');
module.exports = {
    // https://nextjs.org/docs/api-reference/next.config.js/introduction
    // config defined here https://github.com/vercel/next.js/blob/canary/packages/next/next-server/server/config.ts#L12-L63
    distDir: '../dist/ui/.next',
    webpack: (config, { isServer }) => {
        // Fixes npm packages that depend on `fs` module
        if (!isServer) {
            config.node = {
                fs: 'empty',
            };
        }
        const pathsPlugin = new TsconfigPathsPlugin({ configFile: path.resolve(__dirname, 'tsconfig.json') });
        if (config.resolve.plugins) {
            config.resolve.plugins.push(pathsPlugin);
        } else {
            config.resolve.plugins = [pathsPlugin];
        }
        return config;
    },
};
OrenSchwartz commented 3 years ago

getting the same

mthines commented 2 years ago

Applying this patch resolved my issue :)

I'm using yarn@3.

tsconfig-paths-webpack-plugin-npm-3.5.2-7d7e8a5739.patch

diff --git a/lib/plugin.js b/lib/plugin.js
index fb5c8135527f8abf9671ccc8ab6a2e16efe5d5a8..c350b4993b0db61212bf2427ca45e52860898ca7 100644
--- a/lib/plugin.js
+++ b/lib/plugin.js
@@ -14,7 +14,7 @@ class TsconfigPathsPlugin {
         const options = Options.getOptions(rawOptions);
         this.extensions = options.extensions;
         // const colors = new chalk.constructor({ enabled: options.colors });
-        this.log = Logger.makeLogger(options, new chalk.Instance({ level: options.colors ? undefined : 0 }));
+        this.log = Logger.makeLogger(options, chalk);
         const context = options.context || process.cwd();
         const loadFrom = options.configFile || context;
         const loadResult = TsconfigPaths.loadConfig(loadFrom);

Place the patch file in your .yarn/patches/tsconfig-paths-webpack-plugin-npm-3.5.2-7d7e8a5739.patch folder (create the folder if it doesn't exist).

Then adding the resolution to you package.json

package.json

  ...,
 "resolutions": {
    "tsconfig-paths-webpack-plugin@3.5.2": "patch:tsconfig-paths-webpack-plugin@npm:3.5.2#.yarn/patches/tsconfig-paths-webpack-plugin-npm-3.5.2-7d7e8a5739.patch"
  }
}

Then run yarn

Hope it helps somebody 🙂

AndyOGo commented 6 months ago

This usually happens if you set tsconfig paths pointing to node_modules, like:

"paths": {
    "*": ["node_modules/*"]
}, 

While module specifiers that match paths aliases are bare specifiers, once the alias is resolved, module resolution proceeds on the resolved path as a relative path. Consequently, resolution features that happen for node_modules package lookups, including package.json "exports" field support, do not take effect when a paths alias is matched. This can lead to surprising behavior if paths is used to point to a node_modules package: https://www.typescriptlang.org/docs/handbook/modules/reference.html#paths-should-not-point-to-monorepo-packages-or-node_modules-packages