-
Notifications
You must be signed in to change notification settings - Fork 0
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
[Milestone] v1 #1
Comments
So I've flipped on "DRY everything; just use a build script" to now "just use -node and -default suffixes for everything so you don't have to deal with a build script" |
Also recently I've embraced the Node.js convention of using "lib" as a folder name even though it's ignored in Python's default .gitignore. The solution is just don't use lib in py projects and it's OK to use it in Node.js projects. Thus, I've started using src/lib/* where all the internal magic goes instead of src/internal/*. See how that goes. 🤷♀️ |
Also switched opinion on using primordials in everything vs not. The size gains of just using the implicit globals are so good that I don't think it makes sense to use primordial unless you target 100% spec compliance. The tradeoff of smaller bundles in exchange for less "correct" is something that I think is OK to do. |
Also now using universal file-default.ts or file-node.ts suffix on export-conditioned or import-conditioned files that way the base file.ts can be used to route to file-node.ts, but file-default.ts can still be imported explicitly
import hello from "./file.ts" // On Node.js => ./file-node.ts
import helloShim from "./file-default.ts" // EXPLICIT and works
import helloNative from "./file-node.ts" // EXPLICIT works only on Node.js compare that to:
import hello from "./file.ts" // On Node.js => ./file-node.ts
// no way to actually import the shim implementation explicitly 😭
// BUT you can still import the non-default export-condition'ed file
import helloNative from "./file-node.ts" one style vs the other isn't inheritly better, but I think being explicit with the suffixes helps really make it clear that these are export alternatives. 🤷♀️ btw this only works if you do |
also now using vitest since it has out-of-the-box support for most things typescript instead of needing a manual |
isTYPE()
util.types.*
node:util
functionsTarget ESM onlyIdeally, this package would allow consumers to use both ESM and CJS, but ESM-only seems to be the way that things are moving.Also might be worth considering breaking theisTYPE()
functions into a separate package?@jcbhmr/node-util-types
?The text was updated successfully, but these errors were encountered: