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.

Sign up for GitHub

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

Jump to bottom

Add support for jsconfig/tsconfig paths in next/jest #31159

Closed
timneutkens opened this issue Nov 8, 2021 · 3 comments · Fixed by #45815
Closed

Add support for jsconfig/tsconfig paths in next/jest #31159

timneutkens opened this issue Nov 8, 2021 · 3 comments · Fixed by #45815
Assignees
@jankaifer
Labels
please verify canary The issue should be verified against next@canary. It will be closed after 30 days of inactivity SWC Related to minification/transpilation in Next.js.

Comments

@timneutkens
Copy link
Member

timneutkens commented Nov 8, 2021 •
edited

Now that next/jest is supported in order to transform individual files with Jest we want people to be able to adopt it, there's a particular case where people are currently adding babel-plugin-module-resolver which could be moved to using tsconfig.json/jsconfig.json paths but then it would not work with Jest. It'd be helpful if this was supported when using next/jest by default.
@timneutkens timneutkens added SWC Related to minification/transpilation in Next.js. kind: story labels Nov 8, 2021
@jankaifer jankaifer self-assigned this Dec 1, 2022
@jankaifer jankaifer added the please verify canary The issue should be verified against next@canary. It will be closed after 30 days of inactivity label Dec 1, 2022
@github-actions
Copy link
Contributor

github-actions bot commented Dec 1, 2022

Please verify that your issue can be recreated with next@canary.

Why was this issue marked with the please verify canary label?

We noticed the provided reproduction was using an older version of Next.js, instead of canary.

The canary version of Next.js ships daily and includes all features and fixes that have not been released to the stable version yet. You can think of canary as a public beta. Some issues may already be fixed in the canary version, so please verify that your issue reproduces by running npm install next@canary and test it in your project, using your reproduction steps.

If the issue does not reproduce with the canary version, then it has already been fixed and this issue can be closed.

How can I quickly verify if my issue has been fixed in canary?

The safest way is to install next@canary in your project and test it, but you can also search through closed Next.js issues for duplicates or check the Next.js releases.

My issue has been open for a long time, why do I need to verify canary now?

Next.js does not backport bug fixes to older versions of Next.js. Instead, we are trying to introduce only a minimal amount of breaking changes between major releases.

What happens if I don't verify against the canary version of Next.js?

An issue with the please verify canary that receives no meaningful activity (e.g. new comments that acknowledge verification against canary) will be automatically closed and locked after 30 days.

If your issue has not been resolved in that time and it has been closed/locked, please open a new issue, with the required reproduction, using next@canary.

I did not open this issue, but it is relevant to me, what can I do to help?

Anyone experiencing the same issue is welcome to provide a minimal reproduction following the above steps. Furthermore, you can upvote the issue using the 👍 reaction on the topmost comment (please do not comment "I have the same issue" without repro steps). Then, we can sort issues by votes to prioritize.

I think my reproduction is good enough, why aren't you looking into it quicker?

We look into every Next.js issue and constantly monitor open issues for new comments.

However, sometimes we might miss one or two due to the popularity/high traffic of the repository. We apologize, and kindly ask you to refrain from tagging core maintainers, as that will usually not result in increased priority.

Upvoting issues to show your interest will help us prioritize and address them as quickly as possible. That said, every issue is important to us, and if an issue gets closed by accident, we encourage you to open a new one linking to the old issue and we will look into it.

Useful Resources

@balazsorban44
Copy link
Member

This issue has been automatically closed because it wasn't verified against next@canary. If you think it was closed by accident, please leave a comment. If you are running into a similar issue, please open a new issue with a reproduction. Thank you.

@Naddiseo Naddiseo mentioned this issue Jan 4, 2023
Closed
@github-actions
Copy link
Contributor

github-actions bot commented Feb 2, 2023

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 2, 2023
timneutkens pushed a commit that referenced this issue Mar 1, 2023
@JohnDaly
[next/jest] Support path aliases from tsconfig/jsconfig (#45815)
725fbc2 
<!--
Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
-->

# Description

fixes #31159
fixes #44553

Path aliases defined in `tsconfig.json` or `jsconfig.json` are not
automatically configured to work with Jest. This means that these
aliases have to be defined in multiple places.

This PR configures the SWC Jest transform to handle the `baseUrl` and
`paths`, so that users don't need to configure a `moduleNameMapper` for
Jest.

~This PR intends to make the experience more seamless by automatically
configuring Jest's `moduleNameMapper` and `moduleDirectories` based on
the settings in a project's `tsconfig`/`jsconfig`.~

~Users will be able to supply their own configuration for these fields,
if they have use-cases that require manual configuration.~

~The implementation is taken from the [`paths-to-module-name-mapper`
function in
`ts-jest`](https://github.com/kulshekhar/ts-jest/blob/5a0880add0da8d71900eee20c7642e6be65f6a66/src/config/paths-to-module-name-mapper.ts).~

## Bug

- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)

## Feature

- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [x] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)

## Documentation / Examples

- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@jankaifer jankaifer

Labels
please verify canary The issue should be verified against next@canary. It will be closed after 30 days of inactivity SWC Related to minification/transpilation in Next.js.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[next/jest] Support path aliases from tsconfig/jsconfig JohnDaly/next.js
3 participants
@timneutkens @jankaifer @balazsorban44