Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

webpack --watch do not detect changes in files that only export TS interfaces/types etc. #1138

Closed
webpack-bot opened this issue Jul 5, 2020 · 4 comments
Labels

Comments

@webpack-bot
Copy link

Bug report

What is the current behavior?
I believe this issue has been reported in a closed issue (webpack/webpack#8734)
therefore, report again for visibility:
When the only thing a Typescript file exports is an interface, changes to the interface are not seen by watch

I believe files only contain interfaces contain no real Javascript and that is the issue that webpack is not able to detect any changes while transpilation.

Tried the workaround with comments that didn't fix the issue, the only way I were able to get the type only file trigger the build is to have a export { a: 'a' } then import { a } from './typeOnly.ts' - which is not ideal and not practical.

If the current behavior is a bug, please provide the steps to reproduce.
Create a file that only export interface/types:
props.ts

interface Props {
  name: string
}

export default Props

Then create anther file that import props.ts:
component.ts

import React, { FunctionComponent } from 'react';
import Props from './props';

const MyComponent: FunctionComponent<Props> = ({ name }) => (
  <div>{ name }</div>
);

Modify props.ts, either add/change/delete properties in Props then apply those changes to component.ts

Webpack not able to detect the changes in props.ts and the type errors report error on the UI.

See screenshot attached below for example:
Screen Shot 2020-07-05 at 2 40 45 AM

https://github.com/kenilam/Ki.CL is my repos where you can reproduce.

What is the expected behavior?
Webpack watch should be able to pick up file changes that only contain type values

Other relevant information:
webpack version: 4.43.0
Node.js version: 14.4.0


This issue was moved from webpack/webpack#11121 by @sokra. Original issue was by @kenilam.

@johnnyreilly
Copy link
Member

johnnyreilly commented Jul 5, 2020 via email

@kenilam
Copy link

kenilam commented Jul 11, 2020

@jbrantly it turn out it is my lack of Webpack and ts-loader knowledges

I just need to include "importsNotUsedAsValues": "preserve" option to the compiler options in the tsconfig.json.

https://www.npmjs.com/package/fork-ts-checker-webpack-plugin#type-only-modules-watching

Please close this Issue if needed! Thanks

@stale
Copy link

stale bot commented Sep 11, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Sep 11, 2020
@stale
Copy link

stale bot commented Sep 20, 2020

Closing as stale. Please reopen if you'd like to work on this further.

@stale stale bot closed this as completed Sep 20, 2020
jtbandes added a commit to foxglove/studio that referenced this issue May 11, 2021
…orts`

In order to get the correct behavior from webpack watch mode, we need to enable `"importsNotUsedAsValues": "preserve"` in tsconfig (see explanatory comment here: TypeStrong/ts-loader#1138 (comment)).

However, enabling this setting causes conflicts with circular-dependency-webpack-plugins, which now detects circular imports for types. We can avoid this problem by switching to explicit type-only imports (`import type`), which causes TypeScript not to emit the import. There's a lint rule to enforce consistency here: `@typescript-eslint/consistent-type-imports`. (Also disabled `import/no-duplicate` in favor of `@typescript-eslint/no-duplicate-imports` for better TS compatibility).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants