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.

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

paths remapping is not done for type declarations #125

Closed
michaeldzjap opened this issue Dec 17, 2018 · 9 comments
Closed

paths remapping is not done for type declarations #125

michaeldzjap opened this issue Dec 17, 2018 · 9 comments
Labels
controversial kind: feature New feature or request kind: support Asking for support with something or a specific use case solution: duplicate This issue or pull request already exists solution: tsc behavior This is tsc's behavior as well, so this is not a bug with this plugin solution: workaround available There is a workaround available for this issue

Comments

@michaeldzjap
Copy link

Is it possible to use this plugin together with rollup-plugin-alias to replace mapped paths with their "true" paths and if not, would you have a recommendation for a plugin which could do that? I found this. But unfortunately it doesn't resolve my problem or answers my question.

What I am trying to do; I am trying to replace the mapped paths / path aliases (i.e. @src) with the correct path in the transpiled type files. I've tried with the setup below and everything compiles fine. However, my type declaration files that contain a reference to a mapped path are not replaced. So to give an example, I have a Callable.d.ts file after transpilation that looks like

import { Instantiable, Instance } from '@src/Support/types';
declare class Callable<T> {
    private _target;
    private _method?;
    private _isStatic;
    constructor(target: Instantiable<T> | Instance<T>, method?: string, isStatic?: boolean);
    readonly target: Instantiable<T> | Instance<T>;
    readonly method: string | undefined;
    readonly isStatic: boolean;
    asArray(): [Instantiable<T> | Instance<T>, string | undefined, boolean];
    call(args: any[]): any;
}
export default Callable;

instead of

import { Instantiable, Instance } from '../Support/types';
declare class Callable<T> {
    private _target;
    private _method?;
    private _isStatic;
    constructor(target: Instantiable<T> | Instance<T>, method?: string, isStatic?: boolean);
    readonly target: Instantiable<T> | Instance<T>;
    readonly method: string | undefined;
    readonly isStatic: boolean;
    asArray(): [Instantiable<T> | Instance<T>, string | undefined, boolean];
    call(args: any[]): any;
}
export default Callable;

My tsconfig.json, rollup.config.js files and src folder are located at the same (top) level.

Versions

  • typescript: 3.2.2
  • rollup: 0.68.0
  • rollup-plugin-typescript2: 0.18.1

rollup.config.js

import path from 'path';
import resolve from 'rollup-plugin-node-resolve';
import commonjs from 'rollup-plugin-commonjs';
import alias from 'rollup-plugin-alias';
import sourceMaps from 'rollup-plugin-sourcemaps';
import typescript from 'rollup-plugin-typescript2';
import {eslint} from 'rollup-plugin-eslint';
import {terser} from 'rollup-plugin-terser';
import pkg from './package.json';

export default {
    input: 'src/index.ts',
    output: {file: pkg.module, format: 'es', sourcemap: true},
    external: [
        ...Object.keys(pkg.dependencies || {}),
        ...Object.keys(pkg.peerDependencies || {}),
    ],
    watch: {
        include: 'src/**'
    },
    plugins: [
        eslint(),
        resolve(),
        commonjs(),
        alias({
            resolve: ['.ts'],
            '@src': path.resolve(__dirname, './src')
        }),
        typescript({
            typescript: require('typescript'),
            rollupCommonJSResolveHack: true
        }),
        sourceMaps(),
        terser()
    ]
};

tsconfig.json

{
    "compilerOptions": {
        "baseUrl": ".",
        "paths": {
            "@src/*": ["src/*"]
        },
        "emitDecoratorMetadata": true,
        "experimentalDecorators": true,
        "moduleResolution": "node",
        "target": "es6",
        "module": "es6",
        "lib": ["es5", "es6", "es7", "dom"],
        "removeComments": true,
        "strict": true,
        "sourceMap": true,
        "declaration": true,
        "declarationDir": "./dist",
        "outDir": "./dist",
        "suppressImplicitAnyIndexErrors": true
    },
    "include": [
        "src/**/*"
    ],
    "exclude": [
        "node_modules",
        "dist"
    ]
}
@ezolenko
Copy link
Owner

Looks like this should work without rollup-plugin-alias at all. Did you try that? What ends up in the transpiled js?

Somewhat related #112

@michaeldzjap
Copy link
Author

No, without rollup-plugin-alias I get the same result; all mapped paths in the declaration files are not de-mapped (if that is the right word). That's why I tried that plugin in the first place. I will study the issue you linked, thanks.

@ezolenko ezolenko changed the title Usage with rollup-plugin-alias paths remapping is not done for type declarations Dec 18, 2018
@ezolenko ezolenko changed the title paths remapping is not done for type declarations paths remapping is not done for type declarations Dec 18, 2018
@ezolenko
Copy link
Owner

Looks like this is a typescript problem, paths feature is not quite complete(?), see microsoft/TypeScript#16088 and microsoft/TypeScript#27218.

Try removing baseUrl and paths from tsconfig and instead do all remapping with rollup-plugin-alias, so that paths are expanded by the time typescript sees them. This might break intellisense in your IDE though.

@michaeldzjap
Copy link
Author

Ah I see. Boy, I'm having a hard time liking TypeScript to be honest. Always something...

Anyway, I tried your suggestion, leaving out baseUrl and paths and only use rollup-plugin-alias, but then I get an

semantic error TS2307 Cannot find module '@src/...'.

error. So obviously the TypeScript compiler doesn't like it when you attempt to use custom formatted paths without explicitly telling it so. That makes sense actually. I think I will leave the whole path mapping for now and just go back to using relative paths. Kind of regret having to do this, but it is not worth all the trouble I am running into here.

@iliyaZelenko
Copy link

iliyaZelenko commented Apr 7, 2019

I have the same problem. My package with issue.

How to make path in .d.ts relative?

Without rollup-plugin-alias I have:

image

@zerollup/ts-transform-paths package helps me (zerkalica/zerollup#11) .

@josketres
Copy link

I could do the paths remapping with @zerollup/ts-transform-paths

zerkalica/zerollup#11

@iliyaZelenko thanks for the hint!

@viT-1
Copy link

viT-1 commented Aug 22, 2019

Another way is try to configure rollup-plugin-typescript2 with typescript: ttypescript and tsconfig.json > compilerOptions > "plugins": [{ "transform": "typescript-transform-paths" }]

@developer239
Copy link

developer239 commented Feb 26, 2021

// tsconfig.build.json

// ...
"moduleResolution": "node",
"plugins": [
  {
    "transform": "@zerollup/ts-transform-paths",
    "exclude": ["*"]
  }
]
// ...
// rollup.config.js

/* eslint-disable import/no-default-export */
import cleaner from 'rollup-plugin-cleaner'
import typescript from 'rollup-plugin-typescript2'
import ttypescript from 'ttypescript'

export default {
  input: `./src/index.ts`,
  output: [
    { file: 'lib/index.js' },
  ],
  plugins: [
    cleaner({
      targets: ['./lib'],
    }),
    typescript({
      tsconfig: 'tsconfig.build.json',
      typescript: ttypescript
    }),
  ],
}

@agilgur5 agilgur5 added solution: tsc behavior This is tsc's behavior as well, so this is not a bug with this plugin kind: feature New feature or request controversial solution: workaround available There is a workaround available for this issue kind: support Asking for support with something or a specific use case solution: duplicate This issue or pull request already exists labels May 13, 2022
@agilgur5
Copy link
Collaborator

Going to mark this as duplicate of #201.
While this issue came first, that one has had a lot more activity, workarounds, etc, so better to continue any discussions there.

Repository owner locked as resolved and limited conversation to collaborators May 13, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
controversial kind: feature New feature or request kind: support Asking for support with something or a specific use case solution: duplicate This issue or pull request already exists solution: tsc behavior This is tsc's behavior as well, so this is not a bug with this plugin solution: workaround available There is a workaround available for this issue
Projects
None yet
Development

No branches or pull requests

7 participants