Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Select an option

  • Save frank-dspeed/1be09eecd1de981ca1eeed1fe86ec05d to your computer and use it in GitHub Desktop.

Select an option

Save frank-dspeed/1be09eecd1de981ca1eeed1fe86ec05d to your computer and use it in GitHub Desktop.
Typescript 4.6 clearing the dust of the new resolve modes

Final Gold Standard for typescript support

First rule is that you need to explicit create .d.ts .d.mts .d.cts alongside your .js files you should try to default to module esnext and you should set the package.json to contain only a main fild that points to a single entrypoint that exports everything from all other entrypoints. and then only the "type": fild to module the name fild should as convention have the same name as the main entrypoint file.

This way all resolve modes should work as long as you import the package by name and place it in node_modules or import it from any location via its relativ path

as rule of thumb i would always take the direct file import that keeps resolve problems to the bare minimum and is easy to archive

create wrapper packages to consume libs with the help of JSDOC Annotations. and try to move away from .ts mts and .cts extensions in your source this way you can keep compiling efforts low while still getting all the compiler hints when needed.

Typescript is a good tool one of the best but it is only a tool it should not stand in your way.

when your package has it self dependencies consider to bundle them to a extra dev-bundle that you commit and include if needed the idea of code deduplication via shared dependencies is a nice idea but in reality it makes more trouble then it solves. You should never relay on npm to solve your dependencie problems and do auto upgrades for you like you would expect them with ^1.0.0 or * everything that is not a pinned dependencie can be considered harmfull and you should only dedupe your dependencies on application level but you need to consider every module as its own encapsulated dependencie that shares nothing else then other own dependencies that you also control.

Tho as rule of thumb every external managed dependencie is a dream you buy into maintainance one or the other way so create your dev bundels. share the code that u used to create the dev bundels.

avoid this hack to get none named imports as default in esm and cjs

exports.default = wasm;
exports.wasm = wasm;
module.exports = Object.assign(exports.default, exports);

deprecate the import bla from './' pattern replace with import {} from './'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment