Strange warning stating that export does not exist when it does

[domehead100]

Bug report

What is the current behavior?

Not sure if this is a problem with a loader or webpack itself, but on a project that is using typescript, I'm getting a warning:

    WARNING in ./React/src/components/_shared/form/form-model.ts
    17:0-39 "export 'IValidation' was not found in '_types/IValidation'"
        at HarmonyExportImportedSpecifierDependency._getErrors (C:\project\node_modules\webpack\lib\dependencies\HarmonyExportImportedSpecifierDependency.js:352:11)
        at HarmonyExportImportedSpecifierDependency.getWarnings (C:\project\node_modules\webpack\lib\dependencies\HarmonyExportImportedSpecifierDependency.js:299:15)
        at Compilation.reportDependencyErrorsAndWarnings (C:\project\node_modules\webpack\lib\Compilation.js:985:24)
        at Compilation.finish (C:\project\node_modules\webpack\lib\Compilation.js:817:9)
        at hooks.make.callAsync.err (C:\project\node_modules\webpack\lib\Compiler.js:479:17)
        at _done (eval at create (C:\project\node_modules\tapable\lib\HookCodeFactory.js:24:12), <anonymous>:9:1)
        at _err0 (eval at create (C:\project\node_modules\tapable\lib\HookCodeFactory.js:24:12), <anonymous>:20:22)
        at _addModuleChain (C:\project\node_modules\webpack\lib\Compilation.js:758:12)
        at processModuleDependencies.err (C:\project\node_modules\webpack\lib\Compilation.js:697:9)
        at _combinedTickCallback (internal/process/next_tick.js:131:7)
        at process._tickCallback (internal/process/next_tick.js:180:9)

However, the file in question _types/IValidation, is imported in numerous other files without any warnings being emitted related to those other files that are also importing IValidation from _types/IValidation.

The contents of the file are simple, and there is an "export interface IValidation" in the file:

export enum ValidationType {
    Required,
    Min,
    Max,
    MinLength,
    MaxLength,
}

export interface IValidation {
    validationType: ValidationType;
    errorMessage?: string;
    minValue?: number;
    maxValue?: number;
    maxLength?: number;
    minLength?: number;
}

We do have our "src" directory set as a module resolution root in the resolve section of our webpack config, but I also tried importing the file with a relative path and still get the warning.

I am kind of wondering if this is related to typescript. We are using ts-loader, but we have it doing type checking only and are doing transpiling with babel.

If the current behavior is a bug, please provide the steps to reproduce.
Not sure since I get the warning due to the import of the file in question in one file but not due to several other files that also import the same interface from the same file.

What is the expected behavior?
It should not issue a warning about a missing export if the export clearly exists.

Other relevant information:
webpack version: 4.8.3
Node.js version: 8.9.1
Operating System: Windows 10
Additional tools: webpack-cli 2.1.3

[tryzniak]

Perhaps it would be awesome if you could create a simple project that would reproduce your bug and upload on github.

[sokra]

Interfaces no longer exist after transpiling. For webpack the export doesn't exist.

[domehead100]

True, typescript would remove the interfaces but should also remove the imports.

I'm not sure where the warning is coming from (maybe not from webpack itself).

I'll do some testing and see if I can figure it out.

We never had this happen on webpack 3.10 (were trying to upgrade to 4.8.3).

[Legends]

I guess, it's related to ts-loader then ...

[ooflorent]

@johnnyreilly Can you help us on this?

[rgripper]

Here is a temp solution:
TypeStrong/ts-loader#653 (comment)

[johnnyreilly]

The temp solution suggested by @rgripper should work. I'd be open to baking this into ts-loader since it seems to have bitten a few people... Would anyone like to submit a PR?

[johnnyreilly]

On the linked thread I've put details, a suggestion for implementation and an offer of help if someone wants to submit a PR. Let's see what happens! ❤️ 🌻

[sarod]

We are facing the same issue using babel-loader with https://babeljs.io/docs/en/babel-plugin-transform-typescript

[wclr]

The same problem here for TS types/interfaces after migrating from WP3 to WP4, multiple warnings:

VM606323 index.js:151 ./apps/client/state.ts 3:0-82
"export 'ChartElement' was not found in './cycles/ChartArea/chartElements'

I don't use ts-loader or anything special just simple loader:

const ts = require('typescript')
const tsconfig = require('tsconfig')

const compilerOptions = tsconfig.loadSync(process.cwd()).config.compilerOptions

module.exports = function (source) {  
  const result = ts.transpile(source, { ...compilerOptions, ...this.query })
  return result
}

So it is not a problem of ts-loader

[igorkamyshev]

Hello. I create simple plugin for suppress this error. 👨‍💻

https://github.com/igorkamyshev/ignore-not-found-export-plugin

[anjunatl]

FWIW I only just started seeing this issue today in one of my react/redux/saga projects after refactoring my code layout from:

PageSagas.js
PageActions.js
PageReducers.js

to

feature-A/sagas.js
feature-A/actions.js
feature-A/reducers.js
feature-B/sagas.js
feature-B/actions.js
feature-B/reducers.js
PageSagas.js
PageActions.js
PageReducers.js

to try to organize the growing project a bit more.

Not sure if the duplicate filenames across feature folders could have anything to do with this weird warning display issue.

And because more detail doesn't hurt with debugging, in my particular case the exported function names don't match the filenames right now. They currently look like:

// feature-A/reducers.js :
export default function featureAReducer(...) {}

instead of

// feature-A/reducers.js :
export default function reducers(...) {}

Hope this helps with the debugging. In the meantime, @igorkamyshev 's plugin looks good.

Webpack version info:

• Pulled in via "laravel-mix": "^4.0.14" , which (seems to be using)[https://github.com/JeffreyWay/laravel-mix/blob/v4.0.14/package.json#L63]
• "webpack": "^4.27.1"

[anjunatl]

Update: Some of the files the warnings fired for had both export function X and export default function X snippets in them, some just had one export default function X snippet. All of the warnings went away when I removed all of the default keywords. Hope this helps.

[bodograumann]

@anjunatl, yours seems to be a different issue. This one is about exporting interfaces in typescript and is well understood. There is a comment somewhere explaining it really well, but I currently can not find it. Basically the typescript compiler emits no code for interfaces, so webpack can not find them in the compiled module; except when a module consists of only interfaces. In that case the module will end up completely empty and then webpack will not investigate the exports.

You should probably create a new issue for your problem.

[natew]

@igorkamyshev somehow, no matter using stats or your plugin, I'm still getting errors :/

[igorkamyshev]

@igorkamyshev somehow, no matter using stats or your plugin, I'm still getting errors :/

Sorry, it was deprecated. =(

[elliotbonneville]

Is there currently a way to suppress these errors? I'm not having any luck with Webpack's stat config.

[natew]

For client at least you can: devServer: { clientLogLevel: 'error' } }

…

On Wed, May 8, 2019 at 12:55 PM Elliot Bonneville ***@***.***> wrote: Is there currently a way to suppress these errors? I'm not having any luck with Webpack's stat config. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7378 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAC6RCCN7MRL2BT4JWE3M3PUMV2ZANCNFSM4FBLAUOQ> .

[elliotbonneville]

Thanks, @natew. Is there anything more specific? I'd like to leave other warnings intact.

[MarekLacoAXA]

Maybe this is not a bug, its a feature! (tm) :)
See:
microsoft/TypeScript#28481

When you export your TS interfaces/types in such a style so that it comply with TS's isolatedModules=true, then you won't get these webpack warnings.

import { State } from './interfaces';
export type State = State;

[pcx]

I think @MarekLacoAXA's comment nails the issue for me. I had this error because I was exporting types the same way I was exporting constants. I then split them and used export type for the type alone and it worked. Here's the code:

// ActionNames is a const and ActionTypes is a type

// Before
export { ActionNames, ActionTypes } from "./ActionTypes";

// Above line resulted in warning
// > "export 'ActionPayload' was not found in './ActionTypes'

// Changed the code to the following for the warning to disappear
export { ActionNames } from "./ActionTypes";
export type ActionPayload = ActionPayload;

[Emobe]

@pcx thank you. This actually fixed some huge problem I was having with barrel files. Basically just need to specify the interface to export rather than export * from because it does not compile so it has no idea where to look.

[dsebastien]

I have this issue as well. I've doubled checked my exports but I'm using the correct style.
I've tried multiple solutions but to no avail...

[andresesfm]

I just stumbled upon this issue and I'm wondering about a specific case where webpack/HarmonyImportSpecifierDependency seems to be unable to resolve a decorated + typed class member type, even though it works for another one that gets imported from the same file.

// types.ts
export type ComponentId = string;

export type ItemId = string;

// MyComponent.vue
import { Prop } from './decorators';
import { ComponentId, ItemId } from './types';

export default class MyComponent extends Vue {
  @Prop() readonly id!: ComponentId;

  generateItemId(): ItemId {
    return '123';
  } 
}

In this case, the ComponentId type "cannot be found", whereas the ItemId can. I'm really not sure what's going on here and why it works for one but not for the other - it doesn't look to me as if this would have something to do with how the import file is resolved.

"export 'ComponentId' was not found in './types'

Declaring another function with the ComponentId as return type doesn't change this behavior, only when the decorator itself is gone makes it properly work again.

Have you tried the following?

// MyComponent.vue
import { Prop } from './decorators';
import type { ComponentId, ItemId } from './types'; // <---- adding type here

[archfz]

I got this warning once I upgraded to typescript from 3 to 4. Webpack is 4. From a first peak it seems to reproduce only in files that export only types / interfaces and also import some other types / interfaces from elsewhere.

Typescript introduced type-only exports/import which allows to generate valid JS code when compiling each file on it's own. Without type-only exports/import the TS to JS transformation can't be done when compiling each file on it's own. It's only possible with a full/partial graph of the modules. This is how typescript is designed. There is nothing to do on webpack-side here.

@sokra I am not sure what is going on here. But I was on typescript 3.8.3 previously. As I understand type-only exports/import were introduced in typescript 3.8, so why do I reproduce this issues only once I upgrade to 4.x?

Since compilation works, I'll probably ignore this issue, unless someone has a solution for this.

[KurtPreston]

@andresesfm import type did it! Thank you!

[chuckntaylor]

@andresesfm I have an index.ts file which reexports the types. Using export type { MyTypeOrInterface } from './MyTypeOrInterface' did the trick. Thanks!

[elado]

Is there any way to treat these warnings as errors? I want my build to fail if it shows up. Currently both build and type check (tsc --noEmit) succeed so there's no way to catch this early.

[mgol]

@elado You can set "importsNotUsedAsValues": "error" in tsconfig: https://www.typescriptlang.org/tsconfig#importsNotUsedAsValues

That still allows mixed imports, consisting of both types & values. If you want to ensure types are only imported via import type, you can use the @typescript-eslint/consistent-type-imports ESLint rule.

[archfz]

Back. Now updated to webpack 5. So yeah, what about dynamic / start exports?

export * from './Service/IApiAuthProvider';

My generated types file.

declare namespace api {
    interface IApiAuthProvider {}
    class ApiAuthProvider {}
}
// other namespaces 

Imported in webpacked project as.

import {api} from 'my-module';
import IApiAuthProvider = api.IApiAuthProvider;

How should I handle this? As export type * from doesn't seem to be supported in typescript. See microsoft/TypeScript#38306

[barclayd]

Adding the following will silence the warnings from webpack:

module.exports = {
  ...
  module: {
    parser: {
      javascript: {
        reexportExportsPresence: 'false',
      },
    },
  },
 ...
};

[mwalkerr]

In my case I started getting these warnings after restructuring my project. The project is Spring Boot + React and I had previously kept the JS files under the src/main/resources/static folder. I moved them under a directory called fe and started getting errors like the ones mentioned here.

In my webpack config, I initially had:

resolve: {
...
    modules: [
      path.resolve(__dirname, "./src/main/resources/static/"),
      "node_modules",
    ]
  }

.. after moving everything in to fe, I updated that to:

resolve: {
...
    modules: [
      ".",
      "node_modules",
    ]
  }

.. which resulted in the warnings. I was able to prevent the warnings by updating that to

resolve: {
...
    modules: [
      __dirname,
      "node_modules",
    ]
  }

No idea if this is correct or not but the warnings went away 🤷

[vankop]

@mwalkerr resolve.modules is path to node_modules directories ( by default only node_modules). You can have several of them.

[neirongkuifa]

reexportExportsPresence

It should be:reexportExportsPresence: false,

[coler-j]

Is there a reason you would want reexportExportsPresence to be true?

[mpenney99]

The following works for me:

parser: {
  javascript: {
    importExportsPresence: false
  }
}

importExportsPresence

I was getting this warning on all imports on types in my project after upgrading WebPack 4.41.6 to 5.74.0. It's a large project, so it would not be possible to refactor to type imports everywhere.

[ron23]

@mpenney99 actually you can use eslint to do it for you https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/consistent-type-imports.md

[ropotvs]

Try changing from import { SomeInterface } from '../models';

To import type { SomeInterface } from '../models';