Resolving tsconfig.paths with es module and tsconfig-paths not working #2910
Comments
|
Can you please create a sample project repo with the working mocha setup (as you want it to work ideally) and we'll take a look to see how to configure the same thing in Wallaby? If you like, you may combine the sample repo with the other issue you've raised #2909. |
|
@ArtemGovorov Here's the repo that reproduces the error I am facing.
I am using rushjs to maintain my monorepo and pnpm. Hence you may have to install rushjs.io and pnpm in order to setup this project. You will need to run |
|
@bhvngt - the repo doesn't run for me. I am getting some errors, I'll continue to try get it working... |
|
I'm not sure I've set your repo up correctly but it seems to be working. This is what I did: I tried linking I then changed your ...
+ if (!fs.existsSync('node_modules')) fs.mkdirSync('node_modules');
if (!fs.existsSync(categoryDir)) fs.mkdirSync(categoryDir);
...At this point, I have a number of problems: After creating a package.json |
|
@smcenlly I am sorry for the trouble you went through in setting it up. I missed putting following instructions
{
"name": "wallaby-mocha-rushjs",
"version": "1.0.0",
"description": "",
"type": "module"
}With these the Working Version should have worked fine. After this the other two commits should have reproduced this issue and #2909. |
|
I typically run mocha test from inside each of the sub project folder. you could run |
No problem. Looks like I worked it out correctly :) I will reply for both this issue and #2909 here as the cause is the same. Right now, when you run Wallaby in an ESM context, it does the following things:
In the case of ESM, and specifically when you are using mocha with In short, Wallaby doesn't support either of your cases at the moment, but we have plans to work on this later in the year. I expect we would start this work within the next few months but unfortunately we can't share a timeline right now as there are a number of problems that we don't yet know the solution to. The sharp edges that you're running into at the moment are related to experimental node features. You may already be aware that you are using a number of experimental node features (e.g. https://nodejs.org/api/esm.html#loaders). We had recently had some problems with the latest version of node because of these (the API had breaking changes within existing node versions). As an aside, I'm interested to know how you plan on running your code in production? I understand the use of ESM modules, but technically there's no performance benefit in directly linking to your TypeScript file. Either in your tests or in your production code, the code still needs to be transpiled to JavaScript. If you do it with a custom loader (e.g. One short term option for you (for right now) is to get your tests running from Wallaby using mocha without ESM (e.g. using |
|
Thanks @smcenlly for your reply.
These libraries gets weaved into my
Intermittent
I have tried my hands with Since this is a greenfield project and key components of my architecture (vite, svelte-kit) are Is there an option to supply custom loaders to
I can explore this option. It may workout if the overheads are reasonable and does not affect my larger architectural goal. |
Appreciate your plans and do look forward to it. |
Thanks for explaining.
Understood. I had misinterpreted your earlier comments.
We are personally using
At the moment, yes. Technically it's not something that we officially support and the changes that we want/need to make to better support ESM may make what I'm going to suggest break for you in a future version of Wallaby (if it does, you may need to make some changes to your configuration). We had tried to apply the I believe you'll need to write your own loader. For example:Change your wallaby.cjs configuration file to: ...
env: {
- runner: "--experimental-specifier-resolution=node"
+. runner: "--experimental-specifier-resolution=node --experimental-loader " + require('path').join(__dirname, 'loader.mjs')
}
...
setup: async (wallaby) => {
+ process.env.projectCacheDir = 'file://' + wallaby.projectCacheDir;
+ process.env.localProjectDir = 'file://' + wallaby.localProjectDir;
...
}
...Create loader.mjs with the following content: export function resolve(specifier, context, defaultResolve) {
return defaultResolve(specifier, context, defaultResolve);
}
export function load(url, context, defaultLoad) {
if (url.startsWith(process.env.localProjectDir) && url.endsWith('.ts')) {
url = process.env.projectCacheDir + '/' + url.substring(process.env.localProjectDir.length, url.length - 2) + 'js';
}
return defaultLoad(url, context, defaultLoad);
}This should fix your version that breaks wallaby when typescript is directly linked. It's a little bit hacky but seems to work for me. You would also need to reimplement I am going to close the issue for now as I think we've given you a few options that you should be able to work through. If you have any further problems though, feel free to reply (and we can re-open this issue) or else create a new issue. |
|
This is awesome @smcenlly. With this little hack I was able to completely remove the intermittent build process, making my dev setup much simpler. As a side-effect, my
I completely understand this and I am fine with the compromise since this hack is quiet isolated and minimal.
I was able to completely get around this issue by using self-referencing package with its name which is I am very happy with the setup now. Thanks for your as always awesome support. My DevX with wallabyjs is now multifold better. |
|
@smcenlly I have recently shifted my project to Apple's new M1 based laptop. While doing so, my wallaby setup is breaking. It's throwing
I have updated the sample repo that should reproduce this error. Mocha test when run from respective sub-projects using I tried debugging this and am somewhat at loss on why it is breaking. Error does not seems to be due to Here's the diagnostic dump. |
|
It seems like something must have changed in your project (I assume unrelated to From what I can see, the I was able to fix your problem by updating the loader.mjs import * as path from 'path';
export function resolve(specifier, context, defaultResolve) {
return defaultResolve(specifier, context, defaultResolve);
}
export function load(url, context, defaultLoad) {
if (url.startsWith(process.env.localProjectDir) && url.endsWith('.ts')) {
url = path.join(process.env.projectCacheDir, url.substring(process.env.localProjectDir.length, url.length - 2) + 'js');
}
// Resolve `.ts` files trying to be imported from Wallaby's project cache as JavaScript
if (url.startsWith(process.env.projectCacheDir) && url.endsWith('.ts')) {
url = path.join(process.env.projectCacheDir, url.substring(process.env.projectCacheDir.length, url.length - 2) + 'js');
}
// If for some reason we've asked to load the file by alias, resolve it to the real path
if (process.env.projectCacheDir) {
const nodeModulesLibs = path.join(process.env.projectCacheDir, 'node_modules', '@libs');
if (url.startsWith(nodeModulesLibs)) {
url = path.join(process.env.projectCacheDir, 'libs', url.substring(nodeModulesLibs.length));
}
}
return defaultLoad(url, context, defaultLoad);
} |
|
Thanks @smcenlly. Your solutions works well for me. I am still in dark on how it worked before as I took the same commit and did not make any changes in my sample repo. Guess something must have changed in one of the dependent tool/library in my eco system. |
Issue description or question
I have a monorepo with
esmodule sub-packages. When I usetsconfig-pathswith mocha as described in docs, it fails to resolvepath alias.From this dividab/tsconfig-paths#122, it seems that tsconfig-paths is not supported for
esmmodules. Solutions that have come out requires writing a separate loader. An alternate loader - esbuild-node-loader supports it natively.Does wallaby supports configuring loaders? Currently, my mocha tests runs on cli with the support of these loaders. However, wallaby fails to resolve due to above issues.
Wallaby diagnostics report
The text was updated successfully, but these errors were encountered: