Symlinks to files outside package root are not being compiled

[PavaniVaka]

When symlink is created to the dependency, rollup is giving error Error: Unexpected token (Note that you need plugins to import files that are not JavaScript)

Environment

Versions

• typescript:^3.6.4
• rollup:"^1.26.0"
• rollup-plugin-typescript2:^0.24.3

rollup.config.js

tsconfig.json

package.json

plugin output with verbosity 3

[ezolenko]

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

[PavaniVaka]

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.

[TerenceZ]

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

[thealjey]

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

[ezolenko]

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

[PavaniVaka]

@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.

[thealjey]

@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.

[moki]

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.

[moki]

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;

[jesse23]

same issue and rollup-plugin-typescript works

[beenotung]

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

[beenotung]

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.

[agilgur5]

seems to be the same as other resolved issues

When symlink is created to the dependency, rollup is giving error Error: Unexpected token (Note that you need plugins to import files that are not JavaScript)

• rollup-plugin-typescript2:^0.24.3

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

So based on the details mentioned here, this looks to be the same as #216 . While that one came later and describes the problem a bit differently, it also had a reproduction and stated the problem more directly. I was able to root cause both that issue and its rough duplicate, #295 , as well as fix both by upgrading rpt2 to latest.

solution is to upgrade to rpt2 v0.30+ (ideally latest)

Per #216 (comment) and #295 (comment), this was resolved in rpt2 0.30.0, which upgraded upgraded @rollup/pluginutils to v4+, which is responsible for filtering files using plugins' include / exclude.
pluginutils v4 released rollup/plugins#517, which removed the process.cwd() that it was putting in front of nearly all paths -- the addition of process.cwd() upstream made it difficult to include files outside of the project root. This could be considered an upstream bug or feature in that respect.

So if you upgrade to rpt2 0.30+ (ideally just use latest), you should be able to transpile files outside of the package root.

alternative solutions

In older versions of rpt2, changing the include could have worked, as could changing rootDir to ../../, per the linked comments above.

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

Using external can certainly work as well, and may be the more correct solution if you don't want to actually compile the other packages in your monorepos when building an individual package. If they are meant to be external, separate packages, then this is more correct.
If instead, for instance, you have more of a set of common utility functions that are not published but meant for the full code to be included in each individual package, then importing them directly would be more accurate, and external may not be what you want.
It depends.