-
-
Notifications
You must be signed in to change notification settings - Fork 533
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
"Recipes" and "Quick Start:" add a general project config example #1742
Comments
@mindplay-dk we can capture requirements for this more general project configuration example here. I'm copying over some of my questions from the other thread. Getting a second opinion on these ideas will be very helpful in confidently creating the necessary docs updates. Please take a look and let me know what you think.
|
@mindplay-dk friendly reminder to create a project configuration that does not work, as a starting point for this discussion.
Can be posted to a new git repository |
Alright, here's a first draft to get the ball rolling. 🙂 https://github.com/mindplay-dk/ts-node-example I'm targeting Node 16, the current LTS release. I don't know how common it is to target the next version of Node? It may even be more common than targeting the LTS? I also don't know if there are any special considerations or configuration specific to the next version of Node. But let's get a working example for the version recommended by the Node project itself, and maybe we can think about an example for the next version later. I've kept all the I've kept the I've put a comment next to each setting in I'm using I'm approaching this sort-of like a "test suite" - so it just makes a simple test for each of my expectations and prints the result to the console as I'm not sure about all the expectations here. There may be things that can't or shouldn't be supported for some reason? But I would find it confusing if it's valid according to TS and doesn't work with Interestingly, loading both ESM and CommonJS modules does work for some types of imports in this project - it's the first time I've managed that. I've compared the settings against one of my own projects where it doesn't work, and they seem identical - yet, for some reason, Documentation mentions We should probably include an example of importing Documentation also mentions I've left some TODOs in Let me know if you can think of anything else not covered by the example or my notes here? |
@cspotcode I've added you as a collaborator, feel free to go nuts. 😄 |
Also, not clear if What I'm after here is absolute imports, with a It's not clear to me if this package is required only to support path mappings - or if This feature is not important to me, personally - I actually think this does more harm than good. But it probably should be supported and needs an example/test for those who insist on it, so there are as few unpleasant surprises as possible. It's (hopefully) harmless to have this enabled even if it goes unused? |
Great, thanks. Responding to questions in no particular order: tsconfig "paths" and "baseUrl"Path mapping will soon be added to ts-node by #1664. Also, tsconfig-paths does not support ESM, only CJS. (probably why it's not working in the example) So to avoid wasted effort, I think we should focus this example on the near future where ts-node will natively do path mapping.
I'm glad you said this. Yeah, it's a tad frustrating for people to assume this should work. tsconfig "paths" was never intended by the typescript team to be used in this way. Rather, you're supposed to use the features of your runtime environment or bundler to handle import specifiers, and then tell typescript about it using paths. We're not meant to be doing the opposite: bending the runtime to match tsconfig "paths." Node has a bunch of built-in features, such as Node versionNode version is less important than ts-node version. Using node lts is totally fine; especially if it's the latest minor&patch version of it. Very important to use latest ts-node version to ensure you have the latest bugfixes and features. NODE_OPTIONSThe benefit of NODE_OPTIONS is that it gets passed into node processes even when you're not invoking them by typing Import from ansi-colors looks wrong
Where is the |
Took another look at ansi-colors. The issue you are hitting is a node issue, not a typescript nor a ts-node issue. https://nodejs.org/dist/latest-v18.x/docs/api/esm.html#interoperability-with-commonjs Notably:
"static analysis" not "runtime analysis," meaning node is looking at the source code and guessing. In the case of
Static analysis cannot discover any of the properties like
You're stuck using the default export. If |
Oh, but it type-checks - the And look: https://codesandbox.io/s/proud-thunder-zp79ud?file=/src/index.js If that's not supposed to work, why does this work? CSB uses Parcel. Maybe it has better support for CommonJS than Node does? |
Ahh, now I see what you're talking about: https://www.typescriptlang.org/tsconfig/#node12nodenext-nightly-builds
I just assumed that of course TS would support this, but it's not a stable feature yet. I guess for this we'll just have to wait, yeah. |
Are there any plans to support I absolutely despise the fact that TS won't let you use the actual |
We already do with Remember that typechecking is controlled by the compiler, not ts-node. We delegate typechecking to the compiler. Even if we could change the rules in If you're curious to learn more, I recommend googling for why the TS team has decided that the compiler will never rewrite import specifiers in any way. If you want the file extension thing to change, you'll need to convince the TypeScript team, not me. You can ask about this on the TypeScript Discord if you want to discuss with others; it's a great community. |
Is that a
Right, but as you said:
So that's not an option.
Oh, yes - I've come across this thread dozens of times over the years, and I've attempted to debate it more than once. I mean, they don't have to apply the transform - they just have to allow the file extension, so other compilers can support it. I mean, they do this for plenty of things already - most notable NPM packages, which you can't actually use in code that targets the browser, without adding a bundler to actually link packages to make it work. I don't know why allowing yet another thing that isn't actually supported by
Anyhow. Where can I find information about this I want to get that into the example project and make it use imports without the (If you think that makes sense?) |
Oh, it's a node option - and it basically says, "do not use". 🤨
Sounds like something |
Ah, and you meant this would work for the It wouldn't work without the file-extension? So there is no way to do that at the moment with |
Regarding the CommonJS interop, I forgot about a nifty thing that Typescript's node16/nodenext mode does: You can do |
How is that nifty? Ideally, you shouldn't need to think about how modules are implemented. Conceptually, there are modules, and they have members - this is true whether they're implemented as CommonJS or ESM modules. What you want is to reference those members - how they were defined or implemented should be an implementation detail. With bundlers, there are concerns about tree shaking and bundle size and so on - these things don't really matter under Node.JS, so I don't know why the consumer of a package should even need to know or care if the package is internally CommonJS or ESM.
This shouldn't be out of reach for |
I recommend taking some time to spec this out: Write down exactly what your TS should be transformed into so that your imports can be written in exactly the way you are hoping. Use the ansi-colors import as an example. Then think about how that transformation can be done reliably for all kinds of TS code, think about the performance implications (if any). Remember that tricks which work for ansi-colors may actually break for other modules, so keep that in mind. Remember that this will need to be compatible with the code transformers we support: both tsc and swc. Think about the complexity tradeoffs. Think about the rules node imposes upon us, how node behaves at runtime, remembering that we cannot get access to node's internals. |
Can repurpose this for the examples repo: |
Spinning off from conversation started here:
#1007 (comment)
The text was updated successfully, but these errors were encountered: