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
Cannot find module 'ts-node' (yarn) #636
Comments
@alexander-akait 7.2.1 is the version this broke in. Previous versions work fine. You can even see that in 7.1 the problem package |
I can't reproduce, check your version again |
You can check our code https://github.com/webpack-contrib/postcss-loader/blob/master/src/utils.js#L52 |
See https://yarnpkg.com/features/pnp if you don't specify the dependency, yarn will not find it because its resolution is ambiguous. If you want this to be optional you must specify it as an optional peerdependency https://github.com/webpack-contrib/postcss-loader/blob/master/src/utils.js#L56 this line should not be executed unless the dependency is listed in the package executing it. Simply adding this as a peerDep solves this problem. I'm happy to make a PR if you're unsure how to do this. |
Sorry I don't undestand you, we don't use |
Even in loose mode of yarn it will warn you about these bugs |
PR welcome, not sure how we can fix it here, because it is an optinal dependecy, so we can't list it in dependecies |
Only one thing we can do - inline code of the typescript cosmiconfig loader and put everything in peer deps |
I don't think that's necessary, at least with yarn #639 works. I believe this works for pnp as well. |
Not sure about |
It lists it as a peerDep. if it isn't used (require/imported) in the package they should remove it |
That is why I said |
I can't upgrade to As @ntucker has mentioned, if this |
@akphi Because it is yarn and pnp with some magic logic |
Getting hit by the same issue here. Why npm projects keep breaking without any changes even if we set versions in stone? Everytime it's the same thing! We all are busy with other fish to fry, we cannot bother with this now. It's like if you have to go to an appointment with your car and suddenly you're car is not working. Now you have to debug and update the car. NO, I need the car now... Sorry for ranting but this is super frustrating... |
They list @alexander-akait Doesn't matter if you use |
Yes, that's why I included it in my PR https://github.com/webpack-contrib/postcss-loader/pull/639/files. You should be telling @alexander-akait this since he was the one asking about why typescript was needed. |
What we need is a github action that let's library authors verify compatibility easily so random libraries don't accidentally violate these things. Even without those tools not specifying this properly leads to ambiguous resolution, which can lead to incredibly difficult to track down issues. It would have been better if these rules were in place at the inception but that's a lot of ask of new tools |
This still breaks for us. I think because |
And I said it above that it doesn't help, but for some reason no one listened to me |
Yep, I don't think it worked for me, after all, |
The main reason this problem is https://github.com/Codex-/cosmiconfig-typescript-loader/blob/main/package.json#L36:
The latest point for us the same, that is why Ideally |
And yes, I still thinking it should be remove from our |
I suspect this may be because they refer to these types with some of their types. This is less likely to break as typescript has more gracefully fallbacks so I didn't bother looking up if it was necessary and just skipped it in my earlier PR.
https://www.npmjs.com/package/ts-node?activeTab=code ts-node does not list typescript as optional. only @swc/core and @swc/wasm are (this is the peerDependenciesMeta section)
No, ts-node definitely requires typescript. They don't list it as optional. Here is one of their imports https://github.com/TypeStrong/ts-node/blob/main/src/configuration.ts#L2 so it was not a mistake on their part. This makes sense because ts-node is a TypeScript utility - "TypeScript execution and REPL for node.js, with source map and native ESM support." peerDependencies allow packages to utilize the correct version others choose for their package. In this case, it is TypeScript. If you're going to make any package have some interface with TypeScript, you'll need it in your peerDeps. If that functionality is optional then you can make the peer dependency optional. However, having it is absolutely necessary. Furthermore, adding extra peerDeps that aren't even used do not break the package itself or cause it to throw runtime errors - they will simply break during the install phase (never at runtime). Depending on the package manager this might be a warning, an error or they might just ignore the requirements altogether. In no case will it cause runtime errors.
As explained above, its peerdeps are specified correctly as far as typescript is concerned. For @types/node I didn't bother verifying because I was lazy and typescript doesn't fail as hard when the types are missing. |
Just because it works in your case with a less strict manager, that doesn't mean it will break if specify it correctly, nor that it will work with more strict package managers. Additionally, as I mentioned previously the reason they started putting in these stricter rules is because there are a bunch of edge cases that break with packages if these aren't specified correctly. These can still happen in more forgiving tools like swc. The difference is the stricter tools tell you much earlyer (fail early, fail often) rather than waiting of some untraceable confusing error that makes no sense. |
Yup, that's on point. The previous PR only fixed the case for those who are wanting to use it with TypeScript. Since it's optional, the case without typescript must be handled correctly as well. |
That is weird, because if I wanted to avoid using typescript directly (for example for CI/CD and use only swc) and reduce my size of node_modules, I will always have typescript and spend time on it, I feel like it's not right at all.
Using this logic, webpack has We faced with these bugs because our dependecies has wrong logic for peer deps and now we should do the same, now everyone who uses |
Please update - https://github.com/webpack-contrib/postcss-loader/releases/tag/v7.2.4, to avoid memory leak |
If you don't use peerDeps you actually end up with multiple copies of packages which bloats your node_modules size more. I'm not sure how swc works, but newer versions of npm will just install peerDeps even if you don't list them in your project. So you're ending up with typescript somewhere but it might not be resolved correctly. Why do you think you can execute typescript without typescript? If you're having troubles with node_modules size, you should probably use some pnp variant as the majority of the performance issues are related to the numerous files (tho it does lower the size as well). But then if you do that you'll definitely want those peerDeps specified correctly. |
I'm afraid you don't understand me
I am about unnecessary peer dependecies and don't make them optionally
Sorry, I fully disagree with this, again - I don't need typescript, why My question is about why developers add such more things in them peer deps when it can be less and many of them can be optional. |
Bug report
Actual Behavior
Attempts to build using this loader result in the following:
Expected Behavior
https://github.com/Codex-/cosmiconfig-typescript-loader/blob/main/package.json#LL39C6-L39C13
cosmiconfig-typescript-loader has a peerDep of ts-node. This module has cosmiconfig-typescript-loader as a dependency - therefore it should specify ts-node as a dependency as well.
How Do We Reproduce?
ntucker/anansi#1941
https://app.circleci.com/pipelines/github/ntucker/anansi/9024/workflows/561c1fc3-70c1-403c-a033-8175c9788786/jobs/47985
Please paste the results of
npx webpack info
here, and mention other relevant informationThe text was updated successfully, but these errors were encountered: