Filesystem symlinks? What OS, soft or hard links? any change you can make a repo with reproduction?

Windows opertating system. Created symlink using "npm link" option to external module. If module is installed then no problem. But to test locally we need to create symlinks and that is not working only with typescript2 plugin. With typescript1 plugin symlinks are working but enums are not working.

The same issue, but I use lerna to link packages, and rollup complains unexpected token for the linked packages.

exactly the same issue on windows with lerna
If I copy the folder directly into node_modules everything is fine, but with a symlink it does not work

@PavaniVaka @TerenceZ @thealjey any chance for a small repo with reproduction?

@ezolenko Sorry, no. But I narrowed down the issue a bit. I noticed that if the external module is copied to application directory then it works. But if it is just symlink then it is not working. For ex: With yalc we can test the external dependencies easily. Because it creates yalc folder in application directory and copies external module to that folder and then creates symlink from yalc folder to node_modules. Hope this gives some clue.

@ezolenko I have actually figured out what the problem was in my case and it has nothing to do with this plugin (it works perfectly) or symlinks for that matter.
It's more of a shortcoming of typescript itself, or rather its configuration relying on json files.
The problem was that the symlink was resolving to a file outside of CWD.
I simply moved my build command to the top level package.json file and everything started working.

i think we are on the same page here.

194

@PavaniVaka @TerenceZ @thealjey any chance for a small repo with reproduction?

@ezolenko https://github.com/moki/mokui there is one.

I've resolved the issue #194, in case anyone encounters the same problem, below i am providing solution:

When one attempts to build each separate package inside the monorepo, rollup attempts to resolve @organization/package-name and include it in the build. You don't want that, so to avoid it upon building each package i am parsing package.json, extracting the dependencies field's keys, then to check against them inside the callback one can provide inside rollup config's external field. This will produce the desired outcome.

import json from "rollup-plugin-json";

const pkg = process.env.LERNA_PACKAGE_NAME &&
          require(`${process.env.LERNA_PACKAGE_NAME}/package.json`);

const dependencies = ({ dependencies }) => Object.keys(dependencies || {});

const pkgdependencies = dependencies(pkg);

/* exported rollup configuration */
const config = {
    /* your config goes here... */
    /* id is the source name if list of dependencies includes
     * id source name, then mark it as external,
     */
    external: id => pkgdependencies.includes(id)
};

export default config;

same issue and rollup-plugin-typescript works

The problem also occur when a file under the src is symbolic link to a typescript file outside the project.

e.g. the file structure as below:

core/core-client/src/api.ts
myapp/myapp-client/src/api.ts
myapp/myapp-app/src/domain/api.ts -> ../../../myapp-client/src/domain/api.ts
myapp/myapp-app/src/domain/core -> ../../../../core/core-client/src/domain/
...

when I compile the project at myapp/myapp-app,
rollup complaint with below error:

[ ERROR ]  Rollup: Parse Error: ../myapp-client/src/domain/api.ts:28:7
           Unexpected token (Note that you need plugins to import files that are not JavaScript)

     L28:  export interface IPrimus extends Primus {

with the word interface highlighted in red

My workaround is to use pre/post hook in npm script to unlink and link the files ...
So my IDE can check for latest version during dev, and it can compiles when build.