Skip to content
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

Open
4 of 5 tasks
jcbhmr opened this issue Jun 9, 2023 · 5 comments
Open
4 of 5 tasks

[Milestone] v1 #1

jcbhmr opened this issue Jun 9, 2023 · 5 comments
Milestone

Comments

@jcbhmr
Copy link
Member

jcbhmr commented Jun 9, 2023

  • Implement best-guess functions for isTYPE() util.types.*
  • Make package.json better
  • Publish to npm
  • Implement other exposed node:util functions
  • Target ESM only

Ideally, 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 the isTYPE() functions into a separate package? @jcbhmr/node-util-types?

@jcbhmr jcbhmr added this to the v1 milestone Jun 9, 2023
@jcbhmr
Copy link
Member Author

jcbhmr commented Aug 2, 2023

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"

@jcbhmr
Copy link
Member Author

jcbhmr commented Aug 2, 2023

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. 🤷‍♀️

@jcbhmr
Copy link
Member Author

jcbhmr commented Aug 2, 2023

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.

@jcbhmr
Copy link
Member Author

jcbhmr commented Aug 3, 2023

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

[EXPORT_COND=node] file.ts => file-node.ts
[EXPORT_COND=default] file.ts => file-default.ts
file-default.ts
file-node.ts
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:

[EXPORT_COND=node] file.ts => file-node.ts
[EXPORT_COND=default] file.ts => file.ts
file.ts
file-node.ts
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 "./*.js": "./dist/*.js" in your package.json file

@jcbhmr
Copy link
Member Author

jcbhmr commented Aug 3, 2023

also now using vitest since it has out-of-the-box support for most things typescript instead of needing a manual tsx --test test/index.test.ts test/myTest.test.ts for each file. 👈 no node --test doesn't support globs (yet) and test/*.test.ts shell-globs arent Windows compatible

@jcbhmr jcbhmr pinned this issue Aug 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant