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

Not working webpackResolveAlias with next.js #232

Open
yuki153 opened this issue Jan 16, 2024 · 2 comments
Open

Not working webpackResolveAlias with next.js #232

yuki153 opened this issue Jan 16, 2024 · 2 comments
Labels
Type: Fix Fix bug.

Comments

@yuki153
Copy link

yuki153 commented Jan 16, 2024

Hello, thank you for the great tool.
I had a question about this tool and created this issue.

Link to the code that reproduces this issue

https://github.com/yuki153/test-hcm-with-nextjs

To Reproduce

  1. clone repository (yuki153/test-hcm-with-nextjs)
  2. npm run hcm

※ The code for reproduction uses next.js v14.0.4(latest) but, other version (e.g. v12.0.4) also reproduces.

Problem description

Path resolution of next.js succeed, but happy-css-module only fail to resolve path.

Below code that uses alias path at @use fail to path resolve, so d.ts file also doesn't make. But commented out code that does not use alias succeed to make d.ts file.

// @use "../../src/styles/shared.module.scss" as shared;
@use "~/styles/shared.module.scss" as shared;

.headline {
    font-size: 24px;
    color: shared.$accentColor3;
}

Value of webpackResolveAlias is {"~": "../../src"}. Am I mistaken about how to use this alias option?

Error log

~/p/test-hcm-with-nextjs ❯❯❯ npm run hcm                               ✘ 1 

> [email protected] hcm
> hcm 'src/**/*.module.scss' --webpackResolveAlias='{"~": "../../src"}'

[info] Generate .d.ts for src/**/*.module.scss...
`import sass from 'sass'` is deprecated.
Please use `import * as sass from 'sass'` instead.
AggregateError: Failed to process files
    at processAllFiles (file:///Users/user-name/private_git/test-hcm-with-nextjs/node_modules/happy-css-modules/dist/runner.js:90:19)
    at async run (file:///Users/user-name/private_git/test-hcm-with-nextjs/node_modules/happy-css-modules/dist/runner.js:95:9) {
  [errors]: [
    Error: Could not resolve '~/styles/shared.module.scss' in '/Users/user-name/private_git/test-hcm-with-nextjs/src/styles/test2.module.scss'.
      ╷
    3 │ @use "~/styles/shared.module.scss" as shared;
      │ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      ╵
      src/styles/test2.module.scss 3:1  root stylesheet
@mizdra
Copy link
Owner

mizdra commented Jun 16, 2024

@yuki153 Thanks for reporting the issue!

happy-css-modules resolves ~foo to node_modules/foo by default. Perhaps the resolve mechanism is taking precedence over resolve.alias.

// `~` prefix is optional.
// ref: https://github.com/webpack-contrib/css-loader/blob/5e6cf91fd3f0c8b5fb4b91197b98dc56abdef4bf/src/utils.js#L92-L95
// ref: https://github.com/webpack-contrib/sass-loader/blob/49a578a218574ddc92a597c7e365b6c21960717e/src/utils.js#L368-L370
// ref: https://github.com/webpack-contrib/less-loader/blob/d74f740c100c4006b00dfb3e02c6d5aaf8713519/src/utils.js#L72-L75
// eslint-disable-next-line no-param-reassign
if (specifier.startsWith('~')) specifier = specifier.slice(1);

expect(await webpackResolver('~package-1/index.css', { request })).toBe(
getFixturePath('/node_modules/package-1/index.css'),
);
expect(await webpackResolver('~package-2', { request })).toBe(getFixturePath('/node_modules/package-2/index.css'));
expect(await webpackResolver('~package-3/', { request })).toBe(getFixturePath('/node_modules/package-3/index.css'));
expect(await webpackResolver('~package-4', { request })).toBe(getFixturePath('/node_modules/package-4/style.css'));
expect(await webpackResolver('~@scoped/package-5/index.css', { request })).toBe(
getFixturePath('/node_modules/@scoped/package-5/index.css'),
);

I think the problem will be solved if resolve.alias takes precedence over ~ resolve. However, I am not sure if it is compatible with css-loader, scss-loader, and less-loader.

happy-css-modules mimics the resolve mechanism of existing tools to avoid compatibility issues. So I think we need to investigate the precedence order of the resolve mechanism in css-loader, scss-loader, and less-loader.

@mizdra mizdra added the Type: Fix Fix bug. label Jun 16, 2024
@mizdra
Copy link
Owner

mizdra commented Jun 16, 2024

As a workaround, you can use @ instead of ~ for alias.

Also, you should use --webpackResolveAlias='{\"@\": \". /... /src\"}' instead of --webpackResolveAlias='{\"@\": \"src\"}'. The alias should be relative to the directory where happy-css-modules is executed.

// test2.module.scss
@use "@/styles/shared.module.scss" as shared;

.headline {
    font-size: 24px;
    color: shared.$accentColor3;
}
{
  // ...
  "scripts": {
    // ...
    "hcm": "hcm 'src/**/*.module.scss' --webpackResolveAlias='{\"@\": \"src\"}'"
  },
  // ...
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Fix Fix bug.
Projects
None yet
Development

No branches or pull requests

2 participants