Skip to content

[Milestone] v1 #1

Open
Open

Description

@jcbhmr
  • 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?

Activity

  1. added this to the v1 milestone on Jun 9, 2023
  2. jcbhmr commented on Aug 2, 2023

    @jcbhmr
    MemberAuthor

    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"

  3. jcbhmr commented on Aug 2, 2023

    @jcbhmr
    MemberAuthor

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

  4. jcbhmr commented on Aug 2, 2023

    @jcbhmr
    MemberAuthor

    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.

  5. jcbhmr commented on Aug 3, 2023

    @jcbhmr
    MemberAuthor

    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

  6. jcbhmr commented on Aug 3, 2023

    @jcbhmr
    MemberAuthor

    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

  7. pinned this issue on Aug 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions