noUnusedLocals causes problems working in repl

[bogdan]

When ts-node is launched in console mode the noUnusedLocals option causes problems and makes the console hard to use:

$ ts-node
> import {ZnsDomain} from './lib/models'
[eval].ts:1:1 - error TS6133: 'ZnsDomain' is declared but its value is never read.

1 import {ZnsDomain} from './lib/models'
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

undefined

Can we ignore this compiler option when running in console mode or find any other workaround?

[thw0rted]

I was able to run ts-node -O '{"noUnusedLocals": false}'. The quote escapes are important since the parser can't handle single quotes for identifier names, for some reason.

[blakeembrey]

There's also the existing -D option for ignoring diagnostics: https://github.com/TypeStrong/ts-node#cli-and-programmatic-options.

[fan-tom]

Become affected by this issue too, couldn't understand why import * as moment from 'moment' works in one project, but doesn't work in other and requires import moment = require('moment'). Seems very annoying, especially for newbies that try language in REPL

[thw0rted]

@blakeembrey it's been a year. I haven't used the REPL in a while but assuming this is still an issue, would a) be possible and b) make sense, to have ts-node always set the noUnusedLocals option to false, regardless of what's in tsconfig, etc? Thinking about it a little, it's really a nonsense option when you are writing your script one line at a time -- what does "unused" even mean in a REPL?

[cspotcode]

To consider this feature, we'll need to receive a pull request with tests. The creation of a PR will lock down the behavior -- how it interacts with all the other ways we load options -- and enable a proper review.

@thw0rted You say you haven't used the REPL in a while, so you're not sure if this is still a problem. Does this mean that, if we implemented a change, it would not affect you at all? This affects how we prioritize tickets.

For people who use the REPL. what do they use it for? I never use it. I wrote code in an editor, taking advantage of TypeScript's excellent tooling. So it's difficult for me to understand the value of the REPL to other users.

[fan-tom]

I use REPL to check how some functions work, because ts/js usually has no documentation, typings are frequently not precise enough (if exist at all), and to explore behavior in corner cases, like what function return on invalid input (will it throw exception, return null/undefined or some sentinel value). TS/JS ecosystem just have so bad infrastructure (docs, typings, code explorability), that you either try code in REPL or go to sources

[cspotcode]

What benefits do you get from the ts-node REPL as opposed to the node REPL?

If you are trying third-party code, it should not need compilation. If the issue is inaccurate declarations, I assume you would want typechecking turned off. When I don't need typechecking or compilation, I use the node REPL directly. When I want typechecking, I write a temp file in my editor and run it with ts-node-script ./sandbox.ts

[thw0rted]

Yes, this feature would have little impact on me personally, this was more of a sideline commentary. I used the REPL somewhat often, off and on, for a project I haven't needed in a while.

At the time, the use case was that I had written a service that stored its state in a flat-file database. Using the REPL, I could import {db} from "./db" then call methods on it directly to manipulate records. It was very convenient! Instead of e.g. designing a whole CLI wrapper for myself, I was able to do one-off record operations by writing Typescript one-liners.

I will probably need it again at some point, but as I say, for now I can use a workaround, either with the option override when launching ts-node or by using require() syntax instead. My comment from yesterday was just because I came back to the issue, thought "hey, wouldn't it make sense if..." and shared my idea. I still can't imagine any downside, and it sounds like it'd be quick to implement, but I wouldn't prioritize spending a lot of time on it.

[goretkin]

What benefits do you get from the ts-node REPL as opposed to the node REPL?

As a casual visitor of the node universe, I am not familiar with the differences between javascript and typescript. Because of that, it is easier for me if my REPL experience matches code written in .ts files. If my REPL explorations can be in typescript, then I can more easily copy-and-paste some lines from a .ts file into the REPL to see how they work.

[lobsterkatie]

What benefits do you get from the ts-node REPL as opposed to the node REPL?

As a casual visitor of the node universe, I am not familiar with the differences between javascript and typescript. Because of that, it is easier for me if my REPL experience matches code written in .ts files. If my REPL explorations can be in typescript, then I can more easily copy-and-paste some lines from a .ts file into the REPL to see how they work.

... or copy and paste lines from the REPL into my TS file (as I would do with test cases, for instance).

Even as an everyday visitor of the node universe, I second this. A few reasons:

1. I didn't know JS very well when I learned TS, which I now work in exclusively. So a) my knowledge of what works in TS but not JS is somewhat fuzzy, and b) I also don't want to spend brainpower having to worry about it and, if necessary, translating on the fly back into JS just to be able to poke at one function/syntax construct/whatever. Also, what if the thing I want to poke at only exists in TS?

2. Depending on the version of node set for whatever project I'm in, I have to use require rather than import, which is obviously doable but again, kind of a pain when it goes against my everyday muscle memory. (Importing is, of course, how I landed on this issue.)

3. Yes, I can write a small script and run it to test things, but the whole reason to use a REPL is to erase the friction of file creation/deletion, constant switching between editor and command line, re-running of the new version of the script, etc. With a REPL, you type a line, you see what it does. Done. Easy. 😄

Bottom line, as someone who came originally from the Python world, I see the REPL as an integral part of both learning a language and developing in it day to day, and the fact that I can't just import stuff without extra flags/workarounds/etc is something I'd love to see fixed.

Thanks!

[thw0rted]

For anybody just coming to this now, here's a very simple workaround you can use unless/until somebody decides to implement the suggestion I made a while back:

// Save as tsconfig.repl.json.
// Run `TS_NODE_PROJECT=tsconfig.repl.json npm exec ts-node`
{
    "extends": "./tsconfig.base.json", // Assumes you have a "base" tsconfig
    "compilerOptions": {
        "strict": false,               // Strict mode in REPL is not helpful
        "strictNullChecks": false,
        "noUnusedLocals": false,       // ts-node issue #850
    }
}

You could also make a script entry in your package.json, e.g. "ts-repl": "cross-env TS_NODE_PROJECT=tsconfig.repl.json ts-node".