'Iconv is not a constructor' during app warmup #621

New Issue

fergalmoran · 2025-08-09T17:17:00Z

fergalmoran commented

2025-08-09 17:17:00 +00:00

Originally created by @jwhitex on 6/29/2017

We recently deployed our app to a production environment and received the below error. It is followed by a 'FetchFailed' due to inability to parse json. We suspect the later error is a result of the first.

TypeError: Iconv is not a constructor at convertIconv (...\ClientApp\dist\vendor.js:22203:13) 
at convert (...\ClientApp\dist\vendor.js:22166:22) 
at Body.module.exports.Body._convert (...\ClientApp\dist\vendor.js:8573:9) 
at PassThrough.<anonymous> (...\ClientApp\dist\vendor.js:8500:17) 
at emitNone (events.js:91:20) at PassThrough.emit (events.js:185:7) at endReadableNT (_stream_readable.js:974:12) 
at _combinedTickCallback (internal/process/next_tick.js:80:11) at process._tickDomainCallback (internal/process/next_tick.js:128:9)

The fetch which throws the second exception:

export const actionCreators = {
    requestStartupData: (): AppThunkAction<KnownAction> => (dispatch, getState) => {
        let fetchTask = fetch('/api/initialConfig')
            .then(response => response.json() as Promise<HelperTypes.IValidationResult<StartupData>>)
            .then(response => {
                dispatch({ type: 'RECEIVE_STARTUP_DATA', startupData: response.data });
            });
        addTask(fetchTask);
        dispatch({ type: 'REQUEST_STARTUP_DATA' });
    },

The below code produced in vendor.js shows Iconv being set with by a require of module 344. As noted by vendor-manifest.json, Module 344 is 'node-noop'

	var iconvLite = __webpack_require__(240);
	// Load Iconv from an external file to be able to disable Iconv for webpack
	// Add /\/iconv-loader$/ to webpack.IgnorePlugin to ignore it
	var Iconv = __webpack_require__(344);
	
	....

    } else if (Iconv && !useLite) {
	try {
		result = convertIconv(str, to, from);  // this call throws exception
        } catch (E) {
            console.error(E);
            try {
                result = convertIconvLite(str, to, from);
            } catch (E) {
                console.error(E);
                result = str;
            }
        }

Below shows the vendor webpack config where node-noop replaces iconv-loader per your comment.

	
	//webpack.config.vendor.js
	
	    plugins: [
            new webpack.NormalModuleReplacementPlugin(/\/iconv-loader$/, require.resolve('node-noop')),  // Workaround for https://github.com/andris9/encoding/issues/16
            new webpack.DefinePlugin({
                'process.env.NODE_ENV': isDevBuild ? '"development"' : '"production"'
            })
        ]

This appears to be a misuse of 'node-noop' but I'm curious since everyone on the linked thread seems satisfied with this workaround.

Node v6.11.0
SpaServices v1.1.1
DOTNETCORE_ENVIRONMENT=Production

For now we have deployed without serverside rending. Major bummer!

*Originally created by @jwhitex on 6/29/2017* We recently deployed our app to a production environment and received the below error. It is followed by a 'FetchFailed' due to inability to parse json. We suspect the later error is a result of the first. ``` TypeError: Iconv is not a constructor at convertIconv (...\ClientApp\dist\vendor.js:22203:13) at convert (...\ClientApp\dist\vendor.js:22166:22) at Body.module.exports.Body._convert (...\ClientApp\dist\vendor.js:8573:9) at PassThrough.<anonymous> (...\ClientApp\dist\vendor.js:8500:17) at emitNone (events.js:91:20) at PassThrough.emit (events.js:185:7) at endReadableNT (_stream_readable.js:974:12) at _combinedTickCallback (internal/process/next_tick.js:80:11) at process._tickDomainCallback (internal/process/next_tick.js:128:9) ``` *The fetch which throws the second exception:* ``` export const actionCreators = { requestStartupData: (): AppThunkAction<KnownAction> => (dispatch, getState) => { let fetchTask = fetch('/api/initialConfig') .then(response => response.json() as Promise<HelperTypes.IValidationResult<StartupData>>) .then(response => { dispatch({ type: 'RECEIVE_STARTUP_DATA', startupData: response.data }); }); addTask(fetchTask); dispatch({ type: 'REQUEST_STARTUP_DATA' }); }, ``` The below code produced in vendor.js shows ``Iconv`` being set with by a require of module 344. As noted by ``vendor-manifest.json``, Module 344 is 'node-noop' ``` var iconvLite = __webpack_require__(240); // Load Iconv from an external file to be able to disable Iconv for webpack // Add /\/iconv-loader$/ to webpack.IgnorePlugin to ignore it var Iconv = __webpack_require__(344); .... } else if (Iconv && !useLite) { try { result = convertIconv(str, to, from); // this call throws exception } catch (E) { console.error(E); try { result = convertIconvLite(str, to, from); } catch (E) { console.error(E); result = str; } } ``` Below shows the vendor webpack config where ``node-noop`` replaces ``iconv-loader`` per your comment. ``` //webpack.config.vendor.js plugins: [ new webpack.NormalModuleReplacementPlugin(/\/iconv-loader$/, require.resolve('node-noop')), // Workaround for https://github.com/andris9/encoding/issues/16 new webpack.DefinePlugin({ 'process.env.NODE_ENV': isDevBuild ? '"development"' : '"production"' }) ] ``` This appears to be a misuse of 'node-noop' but I'm curious since everyone on the linked thread seems satisfied with this workaround. Node v6.11.0 SpaServices v1.1.1 DOTNETCORE_ENVIRONMENT=Production For now we have deployed without serverside rending. Major bummer!

fergalmoran closed this issue

2025-08-09 17:17:00 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/JavaScriptServices#621