Closed yujeongJeon closed 1 month ago
This is working as intended—it shows that TypeScript doesn’t know anything about the existence of that CSS file, and yet the package.json implies that it’s available to be imported into JavaScript. For TypeScript not to error when a user imports it, either the user needs to have their own declare module "*.css"
block, or the library might choose to add a ./dist/styles/index.d.css.ts
declaration file.
Keep in mind that arethetypeswrong is not prescriptive; it just describes what happens in different module resolvers. A “resolution failed” on a CSS file might be expected behavior for you, but it may not be for everyone. Hiding this information would make the tool less useful, but it’s up to you what to do with the information.
I understand perfectly. thank you for the explanation :)
Hi @arethetypeswrong team,
I'd like to propose an enhancement for the @arethetypeswrong/core package regarding the handling of stylesheet files. Specifically, I'm suggesting that the package ignores "Resolution Failed" checking for files like stylesheets.
Rationale:
When configuring a dual package that supports both CommonJS (CJS) and ESModule (ESM) in the JavaScript module system, it is effective to build the CSS file only once. This is because the CSS file operates the same way regardless of the differences in the JavaScript module system. Therefore, sharing a single built CSS file between ESM and CJS is efficient.
Here’s an example exports map configuration from package.json:
In this configuration, specifying
./styles/style.css
to point to./dist/styles/index.css
for both ESM and CJS is particularly important. This allows the CSS file to be built once and reused across both module systems, saving build time and disk space. Additionally, changes to the CSS file are reflected in all module systems with just one build, which is advantageous for maintenance.Given these benefits, ignoring the "Resolution Failed" checking for stylesheet files would allow developers to maintain efficient build processes without unnecessary complications. This change would maximize build efficiency and streamline the workflow.
Thank you for considering this proposal.