log when there's a key collision

[xavdid]

mirrors to PDE-35 and fixes zapier/zapier-platform-cli#41

Since resources auto-generate keys for their new triggers/etc, we should flag if there's a collision (which will cause confusing behavior).

Notes:

• Currently it just logs, doesn't throw an error (that would be a SEMVER-MAJOR, which we could do if we want (which I would 👍, there's not much to be gained by allowing key collisions)
• Logs very loudly since we check collisions during app compilation, which we do every time we call createAppTester. We could potentially fix this by letting createLambdaHandler know whether or not it's being used for a test or something else, but I think the louder the error is, the better.
• Isn't currently tested (since the only side effect is writing to stdout), but is written in such a way that if we wanted to break it out, it's easy to test

[eliangcs]

Pulled and tested. The change works as expected. But the warning is separated from the other existing ZDW warnings:

ZDW warnings are generated by the backend server. For users to get a nice single consolidated view of all the errors and warnings, maybe it's better to check the key collision in the backend? This will require us to add a new ZDW warning in the doc, though.

[xavdid]

So it turns out that's way tricker than it sounds!

The collision detection has to happen during the code -> definition step. The nice output shown above is generated in CLI, which interfaces with core (and the code itself) via the utils.localAppCommand({ command: 'x' }) utility. All of the methods exposed in core call createLambdaHandler, which in calls a chain (createApp -> schema.prepareApp -> schema.compileApp -> schema.convertResourceDos, the function I'm modifying).

That is to say, the raw code never leaves the core package (so the web and CLI each use the definition, after the keys have been collided). There are a couple of options:

1. Move some table presentation code into core (bad, increases build size for apps)
2. Throw an error instead of just printing that there's an issue (not terrible, probably good to be loud to prevent confusion, is a SEMVER-MAJOR change). CLI will handle the presentation
3. Expose a checkCollisions command in core that returns an array of collisions. It would copy code from the wrapper factory (or move the first few lines into a common ancestor function), check for collisions, and bubble them up (not bad, but more work just so it looks nicer. I agree that the table is nicer, I'm just not sure it's worth it)
4. ship as is
5. 4 right now, 2 whenever the next major ships.

So that's the long answer! Let me know what you think about it

[eliangcs]

@xavdid you're right. By the time the app definition hits the server, the collision is gone and is impossible to detect. I'd vote for 5. But we probably want to add a TODO comment saying that this will be changed to throw an error instead of a warning output.

Another question: Refer to the screenshot above. Why is the warning message printed twice? Can we fix it?

[xavdid]

Sweet, i've added notes in b585611.

As for printing twice, that also can't be fixed without a lot of refactoring. Since the check (and printing) happens whenever createLambdaHandler is called, that happens in every single test (the former is called in createAppTester) and for the definition command (used for the pre-test validation).

Normally I'd want to fix that, but since it's going to be an error later, being extra loud about it (for the few people who will have this issue) isn't really a bad thing. Throwing an error instead of printing will (sort of) fix this, as the message will be shown once and the process will quit.

[eliangcs]

@xavdid sounds fair. 👍