Validate env vars with Zod #2362

infomiho · 2024-10-29T11:04:26Z

This PR will enable us to have strict env vars validation with Zod for Wasp's internal env vars. Also, it will enable users to define their own env var validation. Wasp will use the Zod schemas to output errors for missing env vars.

Left to do

After the strict null checks is merged, make sure that the types are correct Enables strict null checks in SDK #2360
Make sure all env vars in our code are used through the env object and not directly
Experiment with enabling users to add their own env vars validation Enable users to define their env var validations #2363
Update docs (I'm going to do it in a separate PR)
- Make sure to mention the difference between env and process.env
Fix keycloak.env.KEYCLOAK_REALM_URL leftover

Closes #1067

Signed-off-by: Mihovil Ilakovac <[email protected]>

infomiho · 2024-11-29T08:19:03Z

waspc/data/Generator/templates/sdk/wasp/server/config.ts

-    {=/ isAuthEnabled =}
+const allowedCORSOrigins = allowedCORSOriginsPerEnv[env.NODE_ENV]
+
+const config: Config = {


Simplified the creation of the config object, instead of having three separate things all, development, production, now we construct a single object and vary some of the values (e.g. allowed CORS origins) based on NODE_ENV.

Do we loose anyting this way? Anythihg int he old appraoch that was beneficial from having that split? Why was that split there otherwise, I do think it had some benefits possibly?

I think the previous approach we clever since it envisioned many different options for dev and for production, but it in the end, we only vary the CORS origins between dev and production. So, it seemed like an overkill and I know I had these complex types to capture the different objects. But when I looked closer, it turned out this simple Config type is enough.

Ok, makes sense, we can always modify it if needed!

waspc/data/Generator/templates/sdk/wasp/server/email/index.ts

waspc/data/Generator/templates/sdk/wasp/server/env.ts

infomiho · 2024-11-29T08:29:46Z

waspc/examples/todoApp/src/App.tsx

@@ -16,6 +16,7 @@ export function App() {

  const connectionIcon = isConnected ? '🟢' : '🔴'

+  // TODO: enable users to define their own client env vars


Did it in a follow-up PR: #1067

waspc/data/Generator/templates/react-app/package.json

Martinsos

@infomiho looks quite solid to me, improvements in the codebase are visible already! Nice stuff.

I left some comments.

Some general stuff I also had on mind:

What if users try to access our env vars via process.env? I know they can, nothing bad will really happen, but we would rather they use them via our env object, right, so they have better DX (validation happened, types)? This becomes even more important once they start defining their own variables I guess (which is another PR)? I don't think we should in any way forbid them from using process.env of course, that is too crucial of a thing to touch, but I wonder if we should do anything. Maybe monkey patch it in some way so in dev they get a warning that they should use our env object instead? Sounds a bit wild.
process.env and our env object -> are the values in them the same? Shoudl they be? I am guessing they are not the same because of zod default values -> so in env, values will be set to those defaults if they are empty, right? While in process.env, they will not be. This could be confusing for users -> you access variable from env, it has some value, but you know you haven't set it via env, nor anybody else. So how can it have value? Hm. Maybe just documenting this behaviour is good enough.
Just to confirm, what is the behaviour in production now? If some of the env vars are missing and they are required, server will print error and crash? What about in development, it will print errors and also crash or continue?

Martinsos · 2024-12-13T11:30:57Z

waspc/data/Generator/templates/Dockerfile

-# of the bundle and references the dotenv package.
+# Copying 'server/node_modules' because we require dotenv package to
+# load environment variables
+# TODO: replace dotenv with native Node.js environment variable loading


Why is that, what is wrong with dotenv? Node.js now has native support for it that is equally good?

It's always nicer to use natively supported methods than a package to do the same thing. It's available since Node.js 20 and we should probably go for it when Node.js 20 becomes our minimum version.

We should probabl make nodejs 20 our minimum version any moment hm. Ok, so it does do the same thing? If so, great.

waspc/data/Generator/templates/Dockerfile

Martinsos · 2024-12-13T11:42:45Z

waspc/data/Generator/templates/sdk/wasp/env/index.ts

+    if (e instanceof z.ZodError) {
+      const errorOutput = [
+        '',
+        '╔═════════════════════════════╗',


This is cool! I do remember in demo that it was still a bit hard for me to figure out that this is the most important output to look at + where it starts / ends.

Maybe it would be better if it hard clear start and end.
E.g. something like this:

====== Env vars validation failed ====== - error 1 - error 2 - error 3 ========================================

or

====== Env vars validation failed ====== - error 1 - error 2 - error 3 ==== / Env vars validation failed ======

or even

|====== Env vars validation failed ====== | - error 1 | - error 2 | - error 3 |========================================

General idea: we should probably have some kind of universal way for outputing Wasp errors from the TS/JS/node runtime, like we have it for Haskell runtime. E.g. we could have a function defined for it, called consoleWaspError or something like that, that would always format errors like this in a same way. And hopefully it would be similar as the errors we output from the Haskell runtime, so they can easily connect it -> simialr formatting / structure / headers / style / ... .

It might be worth creating this general logging function right now in this PR, it should be quite easy, and then we have it done and can use it? If not ok, we can do it in another PR.

Gotcha, let me do another iteration of this output 👍

I'll create an issue for making this more universal.

Here's the updated version. Related issue: #2420

I see this now -> nice! Why don't you use nice characters for the left border? ╔ and ║ and ╚?

I tried it and I didn't like it actually!

The box looks too polished but it's missing the right border, so this look is kinda less polished and the missing right border doesn't bother me that much visually 🤷

Ok yeah I thought that might be the case. Although this also looks a bit weird. But ok, it is good enough for now, I also don't have better ideas at the moment!

Some quick ideas though:

===== Env vars validation failed ===== > - some text > - some more text > - third problem ======================================

===== Env vars validation failed ===== | - some text | - some more text | - third problem ======================================

or even just

===== Env vars validation failed ===== - some text - some more text - third problem ======================================

Yeah I think I like this one the best.

There will probalby never be more then a couple of these errors, so if you remove those empty lines and make it more compact, you get it all to look quite tight and connected, I think left border might not even be needed then.

Also notice how I put some more = before and after the title, so it doesn't start at the same point where bullets start and looks a bit more like a title I think.

Do as you like though, you can keep it as it is if you prefer that.

I'd drop all the | at the beginning of lines. It's weird and adds no extra info.

Martin's last suggestion is my favorite.
Obviously, I won't argue over this, so you can choose whatever you want :)

Martinsos · 2024-12-13T11:46:41Z

waspc/data/Generator/templates/sdk/wasp/server/config.ts

-    {=/ isAuthEnabled =}
+const allowedCORSOrigins = allowedCORSOriginsPerEnv[env.NODE_ENV]
+
+const config: Config = {


Do we loose anyting this way? Anythihg int he old appraoch that was beneficial from having that split? Why was that split there otherwise, I do think it had some benefits possibly?

waspc/data/Generator/templates/sdk/wasp/server/email/index.ts

waspc/data/Generator/templates/sdk/wasp/server/env.ts

Martinsos · 2024-12-13T12:00:22Z

waspc/data/Generator/templates/sdk/wasp/server/env.ts

Is it bad that this is so centralized? I imagine taht on Haskell side you have to import a ton of things from the codebase in the generator that does this in order to side what goes in and what doesn't. Part of me is tempted to look for a more decentralized appraoch, where each "module" (auth providers, job, email, ...) defines its own env vars and they are somehow all registered in this central place, sure, but they are not all defined in this central place, but it is done via some other mechanism. Maybe that would cause cyclic deps hm, I guess it depends on how you execute it. I haven't thought it through more than this, but you probably did, so I am interested what was your reasoning, why you chose this approach, what are pros/cons.

I think we could build such a system, each part of the framework declares what it needs and declares that for development and production. Then we assemble it in this file by importing those schemas and merge them into one large schema which we use to validate the process.env object.

I feel like it could be useful if we start splitting Wasp into multiple full-stack modules or smth like that. Each module declares what it requires. But ... I think it's maybe an overkill for this PR. This PR wanted to use Zod to validate env vars and make sure all framework code uses validated env vars. I think the decentralised env var schemas system could be a nice improvement if we decide it's worth the extra complexity in the future.

Hm ok yeah, if you don't feel liek this makes our code much worse, then it is ok I believe. We can see how this behaves!

I think we could build such a system, each part of the framework declares what it needs and declares that for development and production. Then we assemble it in this file by importing those schemas and merge them into one large schema which we use to validate the process.env object.

I wanted to suggest exactly this!

I see it as a clear improvement. While I'm OK with postponing it for later, I vote for it now.

This PR wanted to use Zod to validate env vars and make sure all framework code uses validated env vars. I think the decentralised env var schemas system could be a nice improvement if we decide it's worth the extra complexity in the future.

I might be missing something, but it seems we already had a modular (decentralized) system. It wasn't validated but it was modular (at least in terms of auth).
Just adding Zod to improve validation would have made it a fully validated modular system. Instead, we have a fully validated non-modular system.

In terms of validation and type safety, this is a definite improvement.
But, in terms of modularity, it seems like a regression.

EDIT (after looking at everything): Ok, the current Haskell code doesn't look bad at all. And I realize this would be a big change (not everything was modular). So consider my vote for doing it now softened by 50% :)

waspc/src/Wasp/Generator/EmailSenders.hs

Co-authored-by: Martin Šošić <[email protected]>

infomiho · 2024-12-16T08:42:19Z

@Martinsos

What if users try to access our env vars via process.env?

They can, it's part of the Node.js platform - we don't want to deny them that. We offer a convenience method of accessing Wasp defined env variables - which are validated and typed. Monkey patching sounds like it could break some other libraries. that users might want to use in the future - so I think that's not the way to go.

process.env and our env object -> are the values in them the same?

One of them is a raw object, one of them is our validated and typed object. We encourage users to use our env object, while they are free to use the source process.env object as well. We can mention in the docs that there will difference so they are not surprised 👍

Just to confirm, what is the behaviour in production now? If some of the env vars are missing and they are required, server will print error and crash? What about in development, it will print errors and also crash or continue?

Failed validation crashes the server / client - in both development and production. This way it's clear upfront what's wrong vs. having some sort of runtime errors that might not be clear to our users.

Martinsos · 2024-12-16T21:08:39Z

@Martinsos

What if users try to access our env vars via process.env?

They can, it's part of the Node.js platform - we don't want to deny them that. We offer a convenience method of accessing Wasp defined env variables - which are validated and typed. Monkey patching sounds like it could break some other libraries. that users might want to use in the future - so I think that's not the way to go.

process.env and our env object -> are the values in them the same?

One of them is a raw object, one of them is our validated and typed object. We encourage users to use our env object, while they are free to use the source process.env object as well. We can mention in the docs that there will difference so they are not surprised 👍

Just to confirm, what is the behaviour in production now? If some of the env vars are missing and they are required, server will print error and crash? What about in development, it will print errors and also crash or continue?

Failed validation crashes the server / client - in both development and production. This way it's clear upfront what's wrong vs. having some sort of runtime errors that might not be clear to our users.

I believe @sodic suggested we more often quote only small parts of the original message, but in this case I would prefer if you quoted the whole thing, because you left out a lot and I had to go back to my original message to see what I actually wrote, which was not evident here and was missing from the discussion if somebody reads it. Not a biggie though.

Ok, I agree about not touching process.env is probably the best -> btw I advised monkey patching only to print something in dev, exactly because we don't know who might use it, so not to be intrusive, but I guess even that could be surprising in a way, so yeah better not to touch it probably at all.
The thing I think will be confusing is that they will just not be aware of env, and neither will LLM they are using, so we will often be seeing people using process.env instead of env, because they didn't even know env exists. So I am tempted to try to do sometihng about it. Monkey patching does sound intrusive tough, and linter rules or something sound too complex.

On the second thing -> You explained shortly the difference between process.env and env + said we can document it, which is what I already knew / suggested above, but you didn't answer the most interesting (to me) part of my question about default values. That from my perspective is the biggest difference and it could be considered quite unexpected, therefore a source of confusion / wrong assumptions. Have you considered that, and if so, what are your thoughts?

Dev/production craches -> ok great, that is what we want, I was just double checking that is how we did it.

Martinsos

Left some comments but approved!
I would also suggest that @sodic takes a look before merging.

infomiho · 2024-12-17T16:20:29Z

@Martinsos

What if users try to access our env vars via process.env?

They can, it's part of the Node.js platform - we don't want to deny them that. We offer a convenience method of accessing Wasp defined env variables - which are validated and typed. Monkey patching sounds like it could break some other libraries. that users might want to use in the future - so I think that's not the way to go.

process.env and our env object -> are the values in them the same?

One of them is a raw object, one of them is our validated and typed object. We encourage users to use our env object, while they are free to use the source process.env object as well. We can mention in the docs that there will difference so they are not surprised 👍

Just to confirm, what is the behaviour in production now? If some of the env vars are missing and they are required, server will print error and crash? What about in development, it will print errors and also crash or continue?

Failed validation crashes the server / client - in both development and production. This way it's clear upfront what's wrong vs. having some sort of runtime errors that might not be clear to our users.

I believe @sodic suggested we more often quote only small parts of the original message, but in this case I would prefer if you quoted the whole thing, because you left out a lot and I had to go back to my original message to see what I actually wrote, which was not evident here and was missing from the discussion if somebody reads it. Not a biggie though.

Ok, I agree about not touching process.env is probably the best -> btw I advised monkey patching only to print something in dev, exactly because we don't know who might use it, so not to be intrusive, but I guess even that could be surprising in a way, so yeah better not to touch it probably at all. The thing I think will be confusing is that they will just not be aware of env, and neither will LLM they are using, so we will often be seeing people using process.env instead of env, because they didn't even know env exists. So I am tempted to try to do sometihng about it. Monkey patching does sound intrusive tough, and linter rules or something sound too complex.

On the second thing -> You explained shortly the difference between process.env and env + said we can document it, which is what I already knew / suggested above, but you didn't answer the most interesting (to me) part of my question about default values. That from my perspective is the biggest difference and it could be considered quite unexpected, therefore a source of confusion / wrong assumptions. Have you considered that, and if so, what are your thoughts?

Dev/production craches -> ok great, that is what we want, I was just double checking that is how we did it.

Replying to the full message but I'm only replying to the last question.

People use the config object today to get the serverUrl and frontendUrl nowadays. So they are used to using higher level abstractions. env object is something we made up, we document it and say it has default values for certain things. People can use it and there they get the default values. If they use the platform primitive process.env, it's just what they expect. I don't see this is a potential source of confusion - maybe I'm wrong. I'd rather do less at first than more. Let's see how people use this and then put extra guard rails if we see it as a source of problems.

Martinsos · 2024-12-18T11:27:41Z

People use the config object today to get the serverUrl and frontendUrl nowadays. So they are used to using higher level abstractions. env object is something we made up, we document it and say it has default values for certain things. People can use it and there they get the default values. If they use the platform primitive process.env, it's just what they expect. I don't see this is a potential source of confusion - maybe I'm wrong. I'd rather do less at first than more. Let's see how people use this and then put extra guard rails if we see it as a source of problems.

That makes sense to me -> I wanted to hear your thinking on this. Ok, if we make it clear in the docs that it might have default values, then I think that is fine.
Btw I get what you mean by config, but the thing with env and process.env is that they have very similar names and are even more similar in concept, so it is more likely that people will expect them to behave the same, that is why I think it is important to be careful about it.

Martinsos

Approved! One or two small comments left, pls take a look but then do as you like.

waspc/data/Generator/templates/sdk/wasp/client/index.ts

waspc/data/Generator/templates/sdk/wasp/env/index.ts

sodic · 2024-12-19T23:19:35Z

waspc/data/Generator/templates/sdk/wasp/env/index.ts

+    if (e instanceof z.ZodError) {
+      const errorOutput = [
+        '',
+        '╔═════════════════════════════╗',


I'd drop all the | at the beginning of lines. It's weird and adds no extra info.

Martin's last suggestion is my favorite.
Obviously, I won't argue over this, so you can choose whatever you want :)

sodic

Nice, I'm a big fan of this change!

I don't have many comments, Martin covered it well.

waspc/data/Generator/templates/sdk/wasp/server/env.ts

waspc/data/Generator/templates/sdk/wasp/server/index.ts

waspc/data/Generator/templates/sdk/wasp/universal/url.ts

waspc/data/Generator/templates/sdk/wasp/prettier.config.js

sodic · 2024-12-19T23:57:37Z

waspc/data/Generator/templates/Dockerfile

@@ -55,15 +55,15 @@ WORKDIR /app
 # Copying the top level 'node_modules' because it contains the Prisma packages
 # necessary for migrating the database.
 COPY --from=server-builder /app/node_modules ./node_modules
-# Copying the SDK because 'validate-env.mjs' executes independent of the bundle
+# Copying the SDK because the server bundle doesn't bundle the SDK


Are you sure? Why wouldn't it bundle the SDK? It's a dependency like any other (and it's copied with the node modules anyway).

Also, there's the second part of the old comment (below).

I know I wrote the original comment but I am not sure what I meant. But, I think I remember specifically needing it for validate-env.mjs.

Rollup doesn't bundle the wasp/* deps because they are considered "external" deps. I tried making them "internal" (adjust the regex for external deps) and it still didn't want to bundle them. Maybe because they are from node_modules. So, yep, we still need to copy over the SDK in the build context.

Can you add the explanation (or a link to this discussion in the comment)?

waspc/data/Generator/templates/sdk/wasp/server/env.ts

waspc/data/Generator/templates/server/package.json

sodic

Excellent work!

I'm approving, just add this please: #2362 (comment)

infomiho changed the base branch from main to miho-strict-null-checks October 29, 2024 11:25

infomiho added 14 commits October 29, 2024 12:26

WIP: Enables strict null checks in SDK

ddd10d1

Update handleApiError type

90baa94

Throw invalid credentials error explictly

b5c3c63

Formatting

7afc4f0

Update comment and type

b4e2362

Update email env vars

465856c

Update isHttpErrorWithExtraMessage

5c329a4

Update comment

e04aac3

Remove TODO

1928b6f

Fixes jobs types

e231dda

Update todoApp tests. Comment update.

f431153

Update e2e tests

c8b2120

Fixes headless tests

08304fe

Fixes CORS error

a509762

infomiho force-pushed the miho-strict-null-checks branch from 18f9fd0 to a509762 Compare October 29, 2024 11:26

Zod env validation WIP

9d618ea

Signed-off-by: Mihovil Ilakovac <[email protected]>

infomiho force-pushed the miho-zod-env branch from 5f4bb06 to 9d618ea Compare October 29, 2024 11:27

infomiho added 8 commits October 29, 2024 14:59

Define env vars validation. Use validate env vars.

7333b25

Update e2e tests

80baf9c

Clean up

fb899a0

Update SKIP_EMAIL_VERIFICATION_IN_DEV validation

7593ac2

Update headless tests

42d121c

Update headless tests

f877543

Simplify the server config

025d185

Fixes keycloak env usage

1da4542

infomiho mentioned this pull request Nov 20, 2024

Enables strict null checks in SDK #2360

Merged

4 tasks

Base automatically changed from miho-strict-null-checks to main November 26, 2024 14:35

infomiho added 2 commits November 26, 2024 16:07

Merge branch 'main' into miho-zod-env

67de093

Cleanup

ee7c6de

infomiho commented Nov 29, 2024

View reviewed changes

waspc/data/Generator/templates/sdk/wasp/server/email/index.ts Show resolved Hide resolved

infomiho commented Nov 29, 2024

View reviewed changes

waspc/data/Generator/templates/sdk/wasp/server/env.ts Show resolved Hide resolved

infomiho commented Nov 29, 2024

View reviewed changes

Cleanup

88d7ea9

infomiho commented Nov 29, 2024

View reviewed changes

waspc/data/Generator/templates/react-app/package.json Show resolved Hide resolved

infomiho added 2 commits November 29, 2024 10:58

Update e2e tests

107fa51

Update API comment

42e9c78

infomiho mentioned this pull request Nov 29, 2024

Build time validation for client env #2392

Draft

infomiho mentioned this pull request Dec 11, 2024

Update env variables docs #2375

Merged

Martinsos reviewed Dec 13, 2024

View reviewed changes

infomiho and others added 2 commits December 13, 2024 17:07

Update waspc/data/Generator/templates/sdk/wasp/server/env.ts

9dc30c1

Co-authored-by: Martin Šošić <[email protected]>

Merge branch 'main' into miho-zod-env

4766a94

infomiho mentioned this pull request Dec 16, 2024

Create a universal format for outputting errors in Typescript #2420

Open

PR comments

ba46aa8

infomiho requested a review from Martinsos December 16, 2024 12:05

Martinsos approved these changes Dec 16, 2024

View reviewed changes

Martinsos approved these changes Dec 18, 2024

View reviewed changes

sodic reviewed Dec 19, 2024

View reviewed changes

sodic reviewed Dec 20, 2024

View reviewed changes

infomiho added 5 commits January 2, 2025 17:39

Merge branch 'main' into miho-zod-env

920cc90

Cleanup

835e17a

Use single prettier.config.js for all templates

d275338

Update required error messages. jwtTokenSchema conditionally added.

73e5e11

e2e tests

41e24be

sodic approved these changes Jan 7, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Validate env vars with Zod #2362

Validate env vars with Zod #2362

infomiho commented Oct 29, 2024 •

edited

Loading

infomiho Nov 29, 2024

Martinsos Dec 13, 2024

infomiho Dec 13, 2024

Martinsos Dec 16, 2024

infomiho Nov 29, 2024

Martinsos left a comment

Martinsos Dec 13, 2024

infomiho Dec 13, 2024

Martinsos Dec 16, 2024

Martinsos Dec 13, 2024

infomiho Dec 13, 2024

infomiho Dec 16, 2024

Martinsos Dec 16, 2024

infomiho Dec 17, 2024

Martinsos Dec 18, 2024

Martinsos Dec 18, 2024 •

edited

Loading

sodic Dec 19, 2024

Martinsos Dec 13, 2024

Martinsos Dec 13, 2024

infomiho Dec 13, 2024 •

edited

Loading

Martinsos Dec 16, 2024

sodic Dec 19, 2024 •

edited

Loading

infomiho commented Dec 16, 2024

Martinsos commented Dec 16, 2024

Martinsos left a comment

infomiho commented Dec 17, 2024 •

edited

Loading

Martinsos commented Dec 18, 2024

Martinsos left a comment

sodic Dec 19, 2024

sodic left a comment

sodic Dec 19, 2024

infomiho Jan 2, 2025 •

edited

Loading

sodic Jan 7, 2025

sodic left a comment

		@@ -16,6 +16,7 @@ export function App() {

		const connectionIcon = isConnected ? '🟢' : '🔴'

		// TODO: enable users to define their own client env vars

Validate env vars with Zod #2362

Are you sure you want to change the base?

Validate env vars with Zod #2362

Conversation

infomiho commented Oct 29, 2024 • edited Loading

Left to do

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Martinsos left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Martinsos Dec 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

infomiho Dec 13, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sodic Dec 19, 2024 • edited Loading

Choose a reason for hiding this comment

infomiho commented Dec 16, 2024

Martinsos commented Dec 16, 2024

Martinsos left a comment

Choose a reason for hiding this comment

infomiho commented Dec 17, 2024 • edited Loading

Martinsos commented Dec 18, 2024

Martinsos left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sodic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

infomiho Jan 2, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sodic left a comment

Choose a reason for hiding this comment

infomiho commented Oct 29, 2024 •

edited

Loading

Martinsos Dec 18, 2024 •

edited

Loading

infomiho Dec 13, 2024 •

edited

Loading

sodic Dec 19, 2024 •

edited

Loading

infomiho commented Dec 17, 2024 •

edited

Loading

infomiho Jan 2, 2025 •

edited

Loading