HUGO

Tsconfig.json is not being used on 0.78.1

Hi,

I’m using for my website a module written with Typescript. It has a tsconfig.json that contains a path mapping configuration:

{
    "compilerOptions": {
        "target": "es6",
        "module": "CommonJS",
        "lib": [
            "es2018",
            "dom"
        ],
        "moduleResolution": "Node",
        "removeComments": true,
        "preserveConstEnums": true,
        "sourceRoot": "./src/",
        "outDir": "dist",
        "sourceMap": true,
        "jsx": "preserve",
        "baseUrl": ".",
        "paths": {
            "~/*": [
                "src/*"
            ]
        }
    }
}

That path mapping allows me using expressions like ~/utils/test to include file with path ./src/utils/test.

This setup works on Hugo version <= 0.78.0. I recently tried to upgrade to v0.78.1, and encountered with following errors:

While it works without error on 0.78.0:

I’m not sure if this is a bug or an intended change. The following repo is a demo for this issue:

Thanks in advance. :grinning:

It was not my intention to break your setup, but I believe you can get a cleaner setup with the updated import resolution logic.

Have a look at the test project in:

The important things to understand, believe, is:

  • dot imports are relative to the current file.
  • relative imports, e.g. “utils/test” are relative to /assets
  • The above resolves against project and down into theme(s)
  • All package.json/node_modules imports resolves in the main project.
1 Like

Thanks for the reply :grinning:, I’ll take a look at the test project and see if I can adapt to it.

What I’m kinda worried about is the part “relative imports, e.g. “utils/test” are relative to /assets”, because in my actual project, that TSModule folder can be built using npm commands, and it’s hosted in a separate Git repository. I would like it not to depend on Hugo’s environment.

Thanks again for the information. :star:

The hole point of the js.Build abstraction is to make it work with Hugo’s environment.

Note that we do fall back to ESBuild’s resolver for depenencies we don’t find, though I’m not sure what happens in your situation.

I’m not sure if that part is working properly. If I run esbuild command inside TSModule folder, the module can be built without error:

Maybe not, but I don’t understand the problem enough to fix it myself, but I will be happy to accept a well tested patch.

1 Like

But note that /assets does not mean the files needs to live there, you can mount anything into that folder.

I think this will fix your issue:

Will relase a patch release tomorrow.

1 Like

Thanks! Will try it out once it’s released. :grinning:

Thanks for the new release. I have just tried it. But I’m afraid that the error still persists.

@bep

Sorry to bring up again this topic. I got some time today and tried to change my setup.

I read again the replies of this thread, and I thought that I might not have explained clearly my situation.

Let’s say that I have the following folder structure:


assets/someModule
└───src
    │   MainClass.tsx
    │
    ├───components
    │   ├───Component 1
    │   │       index.tsx
    │   │
    │   ├───Component 2
    │   │   │   index.tsx
    │   │   │
    │   │   ├───Component 2.1
    │   │   │       index.tsx
    │   │   │
    │   │   └───Component 2.2
    │   │           index.tsx
    │
    └───utils
            util1.ts

And I would like to import MainClass.tsx inside Component 2.2/index.tsx. Currently, it’s possible to do:

import MainClass from '../../../MainClass.tsx'

But by using tsconfig.json, defining path property, I was able to import that file using the following syntax, which I think could be more clear and easy to write:

import MainClass from '~/MainClass.tsx'

Does Hugo have currently this kind of mechanism? Like redefining paths only for specific modules. In this case, ~ is only applied for files under assets/someModule, and by writing ~, it resolves to some specific path of module, like assets/someModule/src/*

Edit: mechanism to avoid relative-path hell is what I meant to say.

Thanks in advance. :grinning: