-
-
Notifications
You must be signed in to change notification settings - Fork 431
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
Module not found for TypeScript 4.7 #1463
Comments
It's possible that ts-loader doesn't support ECMAScript modules for importing with extensions as you are attempting. Certainly no work has been done to actively support this. We're open to this support being added, though it's not clear at the moment where work would be required. Some questions:
If someone would like to start work on this, we'll happily take a look and collaborate on PRs ❤️🌻 |
I have found a workaround for the time being:
🍻 but I am hitting two other problems:
I've created this branch to test the issues: https://github.com/unional/tersify/tree/webpack Link to |
Although the workaround is done at the webpack config's |
Just in case I have tested older code of that repo. It does look like the |
Roughly the three major bits of NodeNext / mts / cts support in ts-node were: Replace node's resolver with one that checks what I call "alternative file extensions." Every time node's resolver would check for Teach transpiler codepaths to emit Typescript's 2x new flavors of module:
Teach transpiler codepaths to classify files as either CJS or ESM using the same rules as NodeNext
|
Thanks @cspotcode - that's super helpful! @unional it seems like you're super motivated; do you want to have a crack at this? Don't worry too much about tests etc for now; if you can get something working, that's first prize. We can handle the rest later. |
Yeah, I can give it a shot. But need to handle a few things first. Will see if I can get to it. :) |
FYI here is one issue that I found related to source map: |
new NormalModuleReplacementPlugin(/.js$/, (resource) => {
if (/node_modules/.test(resource.context)) return
resource.request = resource.request.replace(/.js$/, '')
}) I found that the workaround needs to be adjusted to this so that it will not remove the Also, it doesn't work when options: {
transpileOnly: true
} My guess is because it can't follow the references. UPDATE: This only works when using the |
@johnnyreilly I notice running Maybe first have a PR to pin the yarn version by using UPDATE: The error detail is:
Trying again in the docker UPDATE2:
um... 🤔 |
Related issue. Maybe when that is available, |
TypeStrong/ts-loader#1463 `transpileOnly: true` doesn't work `tsconfig.cjs.json` doesn't work Use `NormalModuleReplacementPlugin` as workaround
TypeStrong/ts-loader#1463 `transpileOnly: true` doesn't work `tsconfig.cjs.json` doesn't work Use `NormalModuleReplacementPlugin` as workaround
TypeStrong/ts-loader#1463 `transpileOnly: true` doesn't work `tsconfig.cjs.json` doesn't work Use `NormalModuleReplacementPlugin` as workaround
TypeStrong/ts-loader#1463 `transpileOnly: true` doesn't work `tsconfig.cjs.json` doesn't work Use `NormalModuleReplacementPlugin` as workaround
The pnpm test is very out of date - I wouldn't worry particularly about it; it needs refreshing anyway. It's surfaced misleading results in the past as well. It's on my list to do something about. The error message is familiar - I think it came up recently but I can't remember the details.
As to the yarn version; we use v1 but not a specific version. Not a problem if Apologies if I only reply occasionally - I'm on holiday |
NP. That explains all those nice pics. 🌷 |
Cross ref |
I'm back home now @unional - is everything going okay on this? Are you blocked on anything? |
Hi there. I was trying to do a clean run of tests but there is a test failure. Wanted to have a clean start. At the moment I was making some changes to one of my projects as my office work needs it. Was planning to get on this after that. As for the approach, I saw 4.7.3 have the resolve function exposed for |
Sounds good - when you get to it, feel free to stick up a work in progress PR with broken tests if needs be. Will be happy to pair on this |
Have a question about the test system. Is there any reason why it is so slow? Is it because of using karma? (Haven't use karma for ages. 😛 ). If there are things can be done to improve on that (e.g. migrate to This is obvious off-topic to this OP. So if you are interested, we can kick off a discussion about it. 🌷 |
When running the tests in Windows environment, I got this error: START:
Webpack bundling...
Error: EINVAL: invalid argument, mkdir 'C:\Users\homa\AppData\Local\Temp\_karma_webpack_583487\D:\code\others\ts-loader\test\execution-tests\3.6.0_projectReferencesToBeBuilt\lib' Seems like the test setup doesn't work in Windows. |
So there's two test systems; both quite old. The execution tests which run TypeScript tests using Karma and validate if transplantation is working successfully. And comparison tests which are effectively equivalent to Jest snapshot tests. @g-plane tried to do this but we couldn't get it to work on windows - see discussion here: |
I see. I can take a look at it. :) |
They should work on Windows: https://github.com/TypeStrong/ts-loader/runs/6682852223?check_suite_focus=true See the above GitHub Action from 10 days ago running on Windows |
There's a chore piece of work to do with the comparison tests every time there's a major release of TypeScript. I don't think I've done it yet for 4.7. will probably do it on Sunday night |
$ git clean -xfd test/comparison-tests && npm link ./test/comparison-tests/testLib && node test/comparison-tests/run-tests.js
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR!
npm ERR! While resolving: babel-loader@7.1.2
npm ERR! Found: webpack@5.37.1
npm ERR! node_modules/webpack
npm ERR! peer webpack@"^5.0.0" from karma-webpack@5.0.0
npm ERR! node_modules/karma-webpack
npm ERR! dev karma-webpack@"^5.0.0" from the root project
npm ERR! peer webpack@"^5.1.0" from terser-webpack-plugin@5.1.2
npm ERR! node_modules/terser-webpack-plugin
npm ERR! terser-webpack-plugin@"^5.1.1" from webpack@5.37.1
npm ERR! 3 more (webpack-cli, @webpack-cli/configtest, the root project)
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer webpack@"2 || 3" from babel-loader@7.1.2
npm ERR! node_modules/babel-loader
npm ERR! dev babel-loader@"^7.0.0" from the root project
npm ERR!
npm ERR! Conflicting peer dependency: webpack@3.12.0
npm ERR! node_modules/webpack
npm ERR! peer webpack@"2 || 3" from babel-loader@7.1.2
npm ERR! node_modules/babel-loader
npm ERR! dev babel-loader@"^7.0.0" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See /home/homa/.npm/eresolve-report.txt for a full report.
npm ERR! A complete log of this run can be found in:
npm ERR! /home/homa/.npm/_logs/2022-06-11T06_10_04_151Z-debug-0.log
error Command failed with exit code 1. When trying to run on WSL. 🤣 looks fun. |
I see. Likely because my WIndows env is using Node 18. Let me downgrade |
Gosh what would cause that 😂 I use Ubuntu for the most part - which should behave the same but I've not encountered that |
Inside the devcontainer it looks like we use node 16: ts-loader/.devcontainer/Dockerfile Line 6 in 3f8e3a4
|
And node 14 and 16 in our execution test pack: ts-loader/.github/workflows/push.yml Line 78 in 3f8e3a4
|
Running the tests with Node 16 now. btw, running test with Node 16 in WSL still fail the save way as above. Just FYI. 🌷 |
Strange. Just out of curiosity, why don't you fork ts-loader, submit a PR that just changes whitespace or something and see if the tests run successfully there? It'll validate if tests are fundamentally broken. I don't think they are but you never know |
Oh they run - cool |
I wonder if this was the issue: https://stackoverflow.com/a/64615583/761388 |
Ar, I mean "running". 🤣 . It failed. Yeah, trying to figure out what's wrong. Right now I'm suspecting |
Will do. |
It looks like the npm that ships with node 18 had some breaking changes. We use yarn 1 for ts-loader anyway, so I'd advise sticking with that |
My personal coding style is not compatible with the coding style in the repo. I can add a vscode setting to the repo so that it is easier for contributors to create consistent code following the style of the repo. Let me know which one do you use or do you have any other extensions preferences. |
Prettier + ESLint I think
Not sure I understand? Come what may, I think we have a precommit hook set up to format consistently. Generally we use the prettier defaults. |
I can see you've upgraded to TS 4.7.3 - the comparison tests won't work now until I do some fiddling. Execution tests will be fine though |
👌 The issue is when using VSCode and doing format document will mess up the styling. I do that through muscle memory so always need to
Ok. The all the tests "passes" in Windows. |
I'm open to adjusting this - I mostly care that code is formatted consistently. If there's DX tweaks you have in mind we can look at it.
I'll try and do this tomorrow night. Will pop a message on here when done |
#1477 is the PR for that. |
upgrade to 4.7.3 (including test pack) complete |
I have published
|
One update. After I add the |
This is an additional plugin that seems to solve the same problem: https://github.com/softwareventures/resolve-typescript-plugin |
Yeah I'm aware of this. I have an idea that we used to link to this somewhere |
hi, does this problem have been solved by ts-loader or do I have to use other tool to handle it? |
Right now you can workaround it using the workaround mentioned above or using the plugin mentioned above. I don't know what should the general direction for this at the moment, as I just learn that What do you think @johnnyreilly ? |
I'm not sure to be honest. @djcsdy's plugin implies webpack itself didn't support ESM. My guess is that might have changed by now but I don't know. If it has, maybe there's less of a workaround way forward? I'd appreciate anyone who's up to date with where webpack is with this advising? cc @sokra / @alexander-akait |
hm, why don't use https://webpack.js.org/configuration/resolve/#resolveextensionalias? I think it will work |
This in conjunction with Sorry for the +1 without contributing much. Really just coming in here as a user who wanted to convert their project to ESM and is still quite confused about how the different standards work and tools interact. |
Yes, it works! |
Expected Behaviour
Able to bundle.
Actual Behaviour
errors such as:
Steps to Reproduce the Problem
In TypeScript 4.7, the
NodeNext
module resolution requires the source code to specify the extension as.js
.e.g.:
For
ts-jest
on thejest
side,it solves that by doing a transformation:
Maybe something similar is needed?
Would be great to add a section in the readme specifically for that.
Location of a Minimal Repository that Demonstrates the Issue.
Not a minimal repo, but here is an example: https://github.com/unional/tersify.
Run
yarn bundle
in the repo🌷
The text was updated successfully, but these errors were encountered: