Typescript or not, import the the way, it doesn't matter if you use typescript or not.
Typescript is a dialect for development, not for runtime.
I also don't build my node modules back to the old way, my modules on npm have just import/export without a build step.
Out of curiousity, what are the steps you use to import/export without a build step? I have been reading a bit of the docs and found that the two ways. Certainly curious to know your approach :)
I use the type field in the package.json
Than you say that es modules is your default, and if you need common js, you have to change that file extension to cjs.
(e.g. if some old package need a config file in common js format)
The greatest benefit for me is debugging information, what is going on in the dependencies.
(Packages I made and use in my projects)
but, typescript guarantees type safety and rich intellisense, if you dont like typescript check JSDoc. JSDoc provides typings using regular JS comments so, no need for build steps.
examples
/** @type {(string|Array.)} */varfoo;/** @type {number} */varbar=1;/**
* Represents a book.
* @constructor
* @param {string} title - The title of the book.
* @param {string} author - The author of the book.
*/functionBook(title,author){// your code}
JSDoc is indeed very useful for development, it's a standard for me to use it, but it's also not for runtime checking.
I made e.g. npmjs.com/package/@hckrnews/objects for type checking, but there are more packages to guarantee if the data is valid.
Typescript has some nice features, but for me there are also reasons I don't use it for node.js, and I found ways to write clean code that also guarantee that the data is valid.
Clean readable code, strict linting and good tests are very important for me.
For some it can be with typescript, but typescript don't guarantee that your code is good.
Use it if you like it, but it's not the holy grail for good code.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Typescript or not, import the the way, it doesn't matter if you use typescript or not.
Typescript is a dialect for development, not for runtime.
I also don't build my node modules back to the old way, my modules on npm have just import/export without a build step.
@w3nl
Agreed import is the way to go TS/JS!
Out of curiousity, what are the steps you use to import/export without a build step? I have been reading a bit of the docs and found that the two ways. Certainly curious to know your approach :)
nodejs.org/docs/latest-v14.x/api/e...
I use the type field in the package.json
Than you say that es modules is your default, and if you need common js, you have to change that file extension to cjs.
(e.g. if some old package need a config file in common js format)
The greatest benefit for me is debugging information, what is going on in the dependencies.
(Packages I made and use in my projects)
but, typescript guarantees type safety and rich intellisense, if you dont like typescript check JSDoc. JSDoc provides typings using regular JS comments so, no need for build steps.
examples
it enhances intellisense of your code editor.
Visit for more Info
JSDoc is indeed very useful for development, it's a standard for me to use it, but it's also not for runtime checking.
I made e.g. npmjs.com/package/@hckrnews/objects for type checking, but there are more packages to guarantee if the data is valid.
Typescript has some nice features, but for me there are also reasons I don't use it for node.js, and I found ways to write clean code that also guarantee that the data is valid.
Clean readable code, strict linting and good tests are very important for me.
For some it can be with typescript, but typescript don't guarantee that your code is good.
Use it if you like it, but it's not the holy grail for good code.