It's so nice to have this well put together focus on a topic like this. The history of modules in JavaScript is very chaotic and not ideal. But this makes it so much easier to grok my way through issues in the future.
44:45 I think this was because the language server wasn't picking up the correct tsconfig to use. In the GitHub repo, when I rename tsconfig-extensionless.json to tsconfig.json I get an error in the editor. By the way, great talk!
Thought the same thing! This was put into much better words than I was going to put for it. I was thinking it had to do with only being able to use a single tsconfig.json for linting in a particular folder. It does seem like VSCode doesn't really handle prefix-named tsconfig files unfortunately, but I guess that makes sense in the end. Say for when you have one tsconfig for type checking, and one for your build target. I use that to allow checking with my `./test/` files, but to only compile the library code under `./src/` when running the build step.
it's one of those things that everyone has to deal with, but few get to a higher level of understanding. we hope content like this helps! thanks for watching!
Ooh another odd one. VSCode doesn't really provide IntelliSense for it, but it does work at the type-level once written out; you can circularly import a file from itself. Sounds weird, and probably means there's some code stink if that's the case. I mostly use it for testing/demos while checking values available from a barrel exports module. Like this: `/* gg.ts */ import { hi as hiTwo } from "./gg.js"; export declare function hi(): void;`
So a better example of that would be if `hi` was in `submodule.ts`, and if you were to `export * from "./submodule.js";` from `index.ts`. Then from inside `index.ts`, you were to call `import { hi } from "./index.js";`. Wow that was probably a mess to read haha, sorry about that.
wow you're right: it's really tough to accept that that's possible! thanks for providing the use-case though. not sure this would get past code-review in any production codebase (hopefully?). _time to write an ESLint rule!_ lol
An awesome deep dive into the topic of TS modules - thank you!
you're most welcome!
It's so nice to have this well put together focus on a topic like this. The history of modules in JavaScript is very chaotic and not ideal. But this makes it so much easier to grok my way through issues in the future.
thanks for the kind words: this kind of content is exactly what we dreamed of when starting this channel. more to come!
16:25 traceResolution 😮 That's a game changer.
bonus points plz
I grant thee one bonus point
44:45 I think this was because the language server wasn't picking up the correct tsconfig to use. In the GitHub repo, when I rename tsconfig-extensionless.json to tsconfig.json I get an error in the editor. By the way, great talk!
wow! great catch!
Thought the same thing! This was put into much better words than I was going to put for it. I was thinking it had to do with only being able to use a single tsconfig.json for linting in a particular folder. It does seem like VSCode doesn't really handle prefix-named tsconfig files unfortunately, but I guess that makes sense in the end. Say for when you have one tsconfig for type checking, and one for your build target. I use that to allow checking with my `./test/` files, but to only compile the library code under `./src/` when running the build step.
Note that "typings" vs "types", when under the "exports" field, only "types" is valid. "typings" is not. Cheers
good clarification!
Great talk, thank you!
Thanks for taking the time out of your day to watch it!
such an important topic. very misunderstood. especially for bundler configurations in monorepos.
it's one of those things that everyone has to deal with, but few get to a higher level of understanding. we hope content like this helps! thanks for watching!
wow 🥰🥰🥰
my thoughts exactly. we're very happy to be able to share something on such an advanced topic like this.
@@MichiganTypeScript Thanks for sharing, we love Ts💌
why is it so hard to memorize this shit.
Ooh another odd one. VSCode doesn't really provide IntelliSense for it, but it does work at the type-level once written out; you can circularly import a file from itself. Sounds weird, and probably means there's some code stink if that's the case. I mostly use it for testing/demos while checking values available from a barrel exports module. Like this: `/* gg.ts */ import { hi as hiTwo } from "./gg.js"; export declare function hi(): void;`
So a better example of that would be if `hi` was in `submodule.ts`, and if you were to `export * from "./submodule.js";` from `index.ts`. Then from inside `index.ts`, you were to call `import { hi } from "./index.js";`. Wow that was probably a mess to read haha, sorry about that.
wow you're right: it's really tough to accept that that's possible! thanks for providing the use-case though. not sure this would get past code-review in any production codebase (hopefully?). _time to write an ESLint rule!_ lol