Closed jimmywarting closed 3 years ago
The change in this PR unfortunately means that some developers would no longer be able to use this library, as we're no longer shipping a CJS module.
They can still import it using the async syntax import('ms')
I (personally) feel that TypeScript might actually be a better solution here as we could use it to generate ES and CJS modules, and also emit types.
You can still do that with allowJS + checkJS + plus you would not need to waste time compiling.
Hi @jimmywarting, sorry for the slow response.
They can still import it using the async syntax import('ms')
I've discussed this with a few colleagues, and we still think we should ship ESM and CJS:
import()
would require some users to reimplement ms
, which we can avoid by shipping CJS alongside ESM.You can still do that with allowJS + checkJS + plus you would not need to waste time compiling.
I like the approach, and use it myself sometime for small utilities, but this is only good internally. TypeScript would allow us to ship types - which we don't do today - saving over 700,000 additional package downloads a week. That's a win for our users, and the environment :)
The cost of compiling this to CJS and ESM with TypeScript is around 2.8s on my M1, so I don't think it's a notable cost here.
Are you OK to make these changes? No pressure if not! I can take a look at this over the next few days.
Are you OK to make these changes? No pressure if not! I can take a look at this over the next few days.
If you want typescript, then fine by me. The outcome is the same for me. just don't expect any more PR from me. Love typing but hate the syntax and not being able to run things natively in browser... still prefer jsdoc over ts and non bundled files for easier code spliting. Lot's of Typescript project unfortunately bundle everything together... (but you only have one index file so it don't apply to u)
I like the approach, and use it myself sometime for small utilities, but this is only good internally. TypeScript would allow us to ship types - which we don't do today - saving over 700,000 additional package downloads a week. That's a win for our users, and the environment :)
You can still utilize typescript to generate d.ts from vanilla js + jsdoc and i do think your project is considered a "small utility" that typescript isn't even worth it. https://www.typescriptlang.org/docs/handbook/declaration-files/dts-from-js.html
I use typescript myself (but only for it's typing support - using jsdoc) I never use the typescript syntax. best part of it is that you can
i don't like build tools as much as everyone other typescript user dose. i prefer buildless projects and files that can be imported in all environments (Deno, Browser & Nodes http loader) for best cross compatible code
infact if you try out the Deno plugin for VSCode and import this vanila js library (as an example) written in ESM and JSDoc
...then you do get typing support (and description as well) and you won't need any extra d.ts
files or any NPM package manager
Pretty sweet if you ask me
typing is baked in into the vanila js file itself with jsdoc
Thanks for your time on this @jimmywarting. I'll make the changes as discussed, I've just opened #163 for early feedback and hope to ship this within the next week.
fyi, this is the tsconfig i mostly use on all my projects
{
"include": ["*.js"],
"compilerOptions": {
"target": "ES2020",
"lib": ["ES2020"],
"module": "ES2020",
"moduleResolution": "node",
"allowJs": true,
"checkJs": true,
"declaration": true,
"emitDeclarationOnly": true,
"allowSyntheticDefaultImports": true,
"skipLibCheck": true,
"strictNullChecks": true
}
}
Gives u all the benefits of typescript without actually writing any typescript syntax
Closes #159
Personally i don't see any reason for converting it to TypeScript. JSDoc works just as well for providing typing support. ...and dose not require compiling so importing it to Deno with http import gives you typing with ease as well as making it possible to import it using http loader from browsers and nodes new HTTP loader