Publish @arethetypeswrong/core

[andrewbranch]

Closes #12

v0.0.4 was published manually. We’ll see if publishing from GH Actions works in v0.0.5 😄

cc @markerikson

[markerikson]

Awesome, thank you!

(that should eliminate the stupid hack I was doing on the weekend that involved using a Node shelljs-based script to clone the attw repo, build it locally, and install it as part of a GH Action... :) )

[markerikson]

FYI I think 0.0.4 is missing a types key for the package :)

[andrewbranch]

There’s no types because there’s no main since I’m only shipping ESM... it doesn’t work in --moduleResolution node10 but I was kind of considering that a feature 😆

[markerikson]

Hmm. You kinda lost me on that one :)

However I have the tsconfig set up in the RTK CI example project using attw didn't seem to pick up any types from @arethetypeswrong/core. VS Code wouldn't acknowledge that the package actually existed at the TS level. Once I added a types key point to dist/index.d.ts via yarn patch, TS picked up the types okay.

[andrewbranch]

That means you’re using --moduleResolution node10 in your project, which can give you strictly wrong results, and you should probably be using --module nodenext for your scripts. What you have will work for importing from the package root, but it will try to get you to import from "@arethetypeswrong/core/dist/checkPackage", when only "@arethetypeswrong/core/checkPackage" will work.

[markerikson]

Hmm. is node10 the same as moduleResolution: "node"?

(FWIW, I know you're the expert here, but this is very unintuitive for me as a consumer of a package, and an example of why I'm trying to go to so many lengths to make sure that RTK does work in as many environments as possible out of the box.)

[andrewbranch]

Yes it is. I renamed it (deprecating the name node) in 5.0 because the name being node is part of the reason people are still using it.

but this is very unintuitive for me as a consumer of a package

I know. I’m sort of intentionally making it difficult to use this package, which is for obsessing over module configuration, without being in the proper module configuration yourself. Both for reasons of irony and because I consider the package to be super pre-release. The upside is that you’ll be a TS modules expert by the end of this process, which I think is a better outcome than I’d get by making the package super backward-compatible 😄

[andrewbranch]

Are you able to use nodenext on your scripts? I’m not actually opposed to adding the types field, I just didn’t think anyone would need it (anyone being you, the only known user of the package 😄)