ts-node: Importing a file outside of the project folder causes: Emit skipped error

Also leaving a comment in case it is useful to someone: this error can also occur if you have "allowJs": true and have a stray *.js file that corresponds to a *.ts file in your project.

I found a combination that worked for me, something about allowJs broke it: tsconfig.json

{
    "compilerOptions": {
        "allowJs": false,
        "target": "ES6",
        "moduleResolution": "node",
        "allowSyntheticDefaultImports": true,
        "module": "commonjs",
        "sourceMap": false,
        "listEmittedFiles": true,
        "alwaysStrict": true,
        "esModuleInterop": true,
        "resolveJsonModule": true,
        "skipLibCheck": true
    },
    "include": [
        "lib/**/*",
        "bin/*",
        "tests/*.test.*"
    ],
    "exclude": [
        "node_modules",
    ]
}

This actually resolved my problem of running ts-node 10.1.0

+  "ts-node": {
+    "transpileOnly": true
+  },

FYI: just in case this is useful some someone. using mocha + typescript + node, I received the same error, and it was because I had a .js file that got written next to the source .ts file. Presumably, even though ts-node isn’t writing the .js files out, it detected that one was there and stopped.

I got the “Emit skipped” error when trying to compile TypeScript code which was not under the ‘rootDir’ (tsconfig.json).

Also leaving a comment in case it is useful to someone: this error can also occur if you have "allowJs": true and have a stray *.js file that corresponds to a *.ts file in your project.

Any solution to this other than turning off allowJs? Would like to compile both versions (.ts & .js) and use each where appropriate. Migrating from JavaScript to TypeScript…

i get Emit skipped error when "allowJs": true is true too

https://github.com/bluelovers/is-req-https

@blakeembrey I have used the latest and greatest:

• typescript v3.3.3
• ts-node v8.0.2
• mocha v5.2.0

My tsconfig.json looks like this:

{
  "compilerOptions": {
    "module": "commonjs",
    "moduleResolution": "node",
    "outDir": "dist",
    "rootDir": "src",
    "target": "es5"
  },
  "exclude": [
    "dist",
    "node_modules"
  ]
}

I tried to use ts-node for my mocha tests which were located in ./test but my rootDir was set to ./src so the following command failed with the message “Emit skipped”:

mocha --bail --require ts-node/register --reporter spec test/main/**/*.ts

I have to admit that the error message sounded a little cryptic to me so I tried to run tsc and tsc failed too and gave me the hint that some of my TS files (the test code) is not in my rootDir, so I moved my tests from ./test to ./src/test and adjusted my mocha script:

mocha --bail --require ts-node/register --reporter spec src/test/main/**/*.ts

Now everything works like expected. 😃

From experimentation this appears to be happening when using ts-node --files with rootDir. I suspect related to the explanation here microsoft/TypeScript#9858

The solution for me was removing rootDir

@jeanlescure I see, I think our scope option is the right choice for you. I put an explanation at the bottom of this comment.

The expansion is actually done by node. You can see this with require.resolve('b'). I believe either TypeScript diagnostics or ts-node display the error with a relative path for readability, but node is the one resolving to an absolute path ending in dist/index.js. Node also follows symlinks by default.

ts-node’s decision to compile is not based on whether the path is relative or not. It’s based on TypeScript’s allowJs and jsx options to decide which file extensions are compiled, and ts-node’s ignore, skipIgnore, scope, and scopeDir options to decide which paths are allowed.

I can understand why your project does not want ts-node to compile other modules in the workspace, but that’s not the case for all projects. Some want to write code across the monorepo and test it all via ts-node without needing to recompile anything manually. Understanding your use-case has been helpful for me, so I appreciate the detailed response.

---

How to use scope on your project today

scope limits ts-node to compiling files only within a given directory, scopeDir. In v10 scope and scopeDir were moved to be API-only options, and TS_NODE_SCOPE was deprecated (Release notes) However, if this option is important to your project, we can un-deprecate it and allow specifying them via tsconfig and CLI flags.

To test this today, I believe you can set env var TS_NODE_SCOPE=true and run your code. scopeDir defaults to your rootDir so it should exclude anything in the b module.

If this works for you, please let me know and we can add it to Discussions as an official recipe.

I have a repo with two packages (let’s call them a and b).

I use yarn workspaces to be able to use package b as a dependency on package a.

When package a imports from package b, it is importing the generated js files under dist (basically as if it was importing from most packages available using yarn add/npm install).

I set up some tests on package a. When I run them using ts-node I get the error:

TypeError: ../b/dist/index.js: Emit skipped

It would seem that ts-node is resolving the symbolic link that yarn sets up pointing to package b as a relative path (hence the ../b in the error) and thus treating that external js as if it was part of the local code.

In my case setting allowJs: false works to solve the problem, confusingly somehow (?), but it seems to be probably an undesired side-effect, that also restricts me from being able to have js files on package a.

For now I’m glad to have a workaround.

Hope this helps others and hope it sheds a light on a possible solution for the TypeScript team.

Cheers

I have since fixed this “emit skipped” error, so recent versions of ts-node should not have this issue. It comes from TypeScript in typechecking mode, where TS may typecheck a file and yet refuse to emit JS for it. I now detect when this happens and use an alternative method to emit to JS. The result is: typechecking still works, and this error goes away.

And of course, nothing changes for transpileOnly mode: the error never existed in that mode. So everything still works.

On Tue, Jun 21, 2022, 4:27 AM Daniel @.***> wrote:

This actually resolved my problem of running ts-node 10.1.0

• “ts-node”: {+ “transpileOnly”: true+ },

Why did this work?

— Reply to this email directly, view it on GitHub https://github.com/TypeStrong/ts-node/issues/693#issuecomment-1161428961, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC35OAFUIRW6OPJVDAEX73VQF4INANCNFSM4FWZAQHA . You are receiving this because you modified the open/close state.Message ID: @.***>

I have the same problem as @jeanlescure. Using yarn workspaces, ts-node refuses to launch a script importing things from another workspace package, and fails with this Emit skipped error.

From experimentation this appears to be happening when using ts-node --files with rootDir. I suspect related to the explanation here https://github.com/Microsoft/TypeScript/issues/9858

Note that modern versions of ts-node entirely avoid this emit skipped error. We detect when the typechecker skips emit, and we fallback to an alternative transpilation. The end result is that users of modern ts-node never see emit skipped even when typechecking.

This actually resolved my problem of running ts-node 10.1.0

+  "ts-node": {
+    "transpileOnly": true
+  },

Why did this work?

It disables type checking, and emit skipped is an issue due to the type checker. It won’t compile files outside the typescript project when it’s type checking them.

@cspotcode scope is exactly what I need. I’ve tested adding TS_NODE_SCOPE=true as you suggested, it works, if I change my rootDir.

You’ve hit the nail in the head because I would actually need to have separate scopeDir and rootDir. In my case I’m only using ts-node to run unit tests which are in a separate directory than src (which is my rootDir), so setting scopeDir to the directory that contains both src and unit-tests by CLI flag or tsconfig.test.json would be ideal.

My vote is for un-deprecate ✋🏼 😄

@cspotcode , as you put it, I’m going to correct you, the assumption is wrong and opposite to what we want 😅

In my case I do not want b to be compiled. No compilation is needed because b is already compiled. A workspace in yarn/npm workspaces is a separate package on the project with its own set of compilation scripts and config. As far as a is concerned, b should be seen as a dependency just like typescript, react, etc.

I think the piece of context missing here is that this is what the import looks like:

import b from 'b';

There is no relative path, this is something that yarn/npm workspaces allows because in the node_modules directory a symbolic link is created.

So what we are saying is, even though the import suggests that b is referring to a package, ts-node is somehow expanding the import to the relative path the symbolic link points to, and in turn interpreting the import as a relative path, thus trying to compile something it’s not supposed to.

I then understand that, with allowJs set to false, this allows node to execute the b/dist/index.js from disk without any compilation. IMHO the logic that allows this should not be attached to allowJs since I want both to be able to have js files in my a package and be able to import the symlinked version of b without it being compiled (as long as the import implies that b is a package and not a relative path to local js code).

As this issue is still open I would like to share my piece. Reading this discussion I found this comment with a lot of likes; https://github.com/TypeStrong/ts-node/issues/693#issuecomment-576123718 which also solved my problem.

How did it happen?

I found that I once compiled my project without specifying an outdir that resulted in every TS file being compiled to JS files in the same path, next time I ran the project the throw a new TypeError('${relative(cwd, fileName)}: Emit skipped').

Solution

Delete every JS file with the same name in the same directory as the TS file, add 'outDir': "Some/path" in your tsconfig.json and you are safe. PS: I experienced Webstorm collapse the JS files in the TS file (If they are called the same) in the IDE, you will have to use the explore to delete the JS or expand every TS file.

Don’t

Do not do allowJs: false to solve this issue, this will literally ignore the TS files and use the compiled JS files, meaning next time you change something in the TS files it won’t use the TS files but the old compiled JS files.

---

Conclusion

It would be awesome if it was possible to add a error message that explained this issue so people don’t have to face this issue since it can be annoying, for use those people that have allowJs: false as default because they won’t notice anything besides that their TS projects are not using the latest changes unless they compile every time they change something.

@marchand-software If you change to require('./foo') then everything can load the .ts file. So you can delete the .js file.