Payload no typescript

[eypacha]

Hello, i search several times and i cannot find the way to install a version without typescript because I need work with javascript directly. Do you know any fork or way to install it? I try change files after installation but i couldn't do it either.

Thanks!

[markbarton-bg]

I don't think you understand.

TypeScript is just a linting tool, an extension that sits on top of your Codebase to ensure you are writing typesafe code. Typescript does not get run on the server or in your browser, the code gets packaged into individual JavaScript modules that get run in. You do not have to use TypeScript when developing Payload Applications, but if you are given the option to run TypeScript then you can definitely run regular JavaScript.

[Publisher5047]

You should learn to use ts. It's very helpful

[josesame]

Horrible answer

[konsumer]

It's not always as "helpful" as you assume, possibly because you have never hit a big time-wasting problem with typescript.

Let me preface my comments with a few facts about me:

• I am decently adept with typescript, and have been using it on-and-off for years (since the beginning.) I am comfortable making my own typedefs, and have done so in lots of projects & libraries. I understand why people like it, even though it's not my thing.
• I am not scared of types in general, and use actually-typed languages often (not this BS fake type-annotation stuff, but like rust & C, actively right now, and in the past java, C#, and many more.)
• I like javascript, especially ESM/6. It's not a perfect language, but it mostly works for what I ever need it for. I have a lot of experience with it, and have made a lot of things with it.

That said, if you are honest with yourself, typescript does add a ton of extra layers to a build, and often does not work, when the issue is essentially "badly defined types". In general I would rather spend my dev-time actually making stuff, rather than fighting some broken typedefs. If the underlying thing (written in JS or ts-transpiled-to-JS) accepts options for example, but they are not in the tyepdefs correctly, you end up with a pretty serious mismatch you have to resolve before you can continue, and will have to look at typedefs instead of whatever you were trying to do. In general, software libraries are sometimes incomplete, get outdated, or just don't work with some old mental-model, and in this build-chain there are already quite a few things that could be broken. Is this "you should use the types correctly"? I don't think so. it's more like "the types are incorrectly defined, because the JS is fine with this, but someone didn't anticipate/update/fix this usecase, even though the underlying thing supports it, fine."

Working in the early days of typescript, I would often have to stop working on everything and hand-make/fix basic typedefs (like common browser APIs, or basic parts of nodejs) before anything would transpile. This is fine if you actually get something from these types being defined (defined again, because the underlying API already defines them, in JS/native/etc) but I don't use an editor that makes dumb type-popups all the time (I am dyslexic, and it destroys my focus and hurts my ability to effectively write code, fast.) It's not something I generally would want even if I did like it, if it doesn't actually match the underlying APIs, as is often the case.

Here is a concrete example:

I make a new project using npx create-payload-app website-payload-example with "website" template, using "Cloudflare D1 SQlite" for database. When I try to npm run build I get this build-stopping error, that didn't show up in npm run dev:

./src/payload.config.ts:62:32
Type error: Cannot find name 'cloudflare'.

  60 |   // This config helps us configure global or default features that the other editors can inherit
  61 |   editor: defaultLexical,
> 62 | db: sqliteD1Adapter({ binding: cloudflare.env.D1 }),
     |                                ^
  63 |   collections: [Pages, Posts, Media, Categories, Users],
  64 |   cors: [getServerSideURL()].filter(Boolean),
  65 |   globals: [Header, Footer],
Next.js build worker exited with code: 1 and signal: null

so I need some global typedef for cloudflare. If I use create-payload-app again, I chose "with-cloudflare-d1" template, and I see that it outputs some separate & jenky global cloudflare typedefs (in cloudflare-env.d.ts.) I copy that file into my project, and it still does not build. It probably needs some extra step, which isn't documented anywhere. I look at tsconfig.json, and they are the same. After shuffling more files around, eventually I get past this error, and then I see:

Type error: Module '"@/payload-types"' has no exported member 'ArchiveBlock'.

> 1 | import type { Post, ArchiveBlock as ArchiveBlockProps } from '@/payload-types'
    |                     ^
  2 |
  3 | import configPromise from '@payload-config'
  4 | import { getPayload } from 'payload'
Next.js build worker exited with code: 1 and signal: null

This is some sort of circular-definition, where ArchiveBlock type is generated from ArchiveBlock/Component.tsx, but ArchiveBlock/Component.tsx imports that type, so there is no good way to auto-generate it. I am sure I could pull the definitions carefully out of the generated types and put them in my own generated types (against the advice in the comments of that file) which would make the type-generation work correctly, but you have to admit, that is pretty gross, and not at all intuitive. I am sure it's some simple thing, but I have already wasted 20 minutes fighting with typescript instead of making the thing I wanted to make, and this is my first taste of PayloadCMS, which makes me just want to use something else. This is what is in the "quick start", on the website.

As you say "TypeScript is just a linting tool, an extension that sits on top of your Codebase" but it actively prevents the build, even through the underlying API supports those options (and it would have been fine without the types.) In this case, what problem is it solving? It definitely adds time to my build even when it's working right, and it doesn't actually help me configure the thing, which is now totally broken, so I'll have to revert back to a simpler template, and build it up manually, hoping to not recreate the issue (which I will, because that is essentially what I already did, but maybe I will slowly find a better path.)

Personally, I would often rather strip all the ts BS, and get it working, than try to fix the typedefs. It's often as much rooting around in someone else's code, fixing things, but the end-product is no more type-BS, and I can get on with my dev-time.

I'm not looking for a resolution to my specific problem here (these issues should be reported elsewhere, and are obviously a problem with the project-templates or some typedefs or documentation) but it may help explain why some people just don't care for typescript. It's cool you like it, but try the above, and time yourself, a person who actually likes typescript, in fixing it. Was it less than 30 minutes, before you could start working on what you were originally trying to make? If you have 20 lil sessions of this, that's at least 10 hours, before you are even making what you wanted to.

[tyteen4a03]

Sentiments against TypeScript aside (the dynamic vs static language debate has been going on since forever), any "bad typings" that Payload generates should be a bug report with Payload.

[konsumer]

For sure, I mention this a the end of my rant. My point is that this discussion is a person who doesn't want to use typescript, which is often a totally valid choice, and the response of "learn to use it" is not really adequate or helpful. Me ranting about how lame typescript is probably isn't either, though.