Restored files that were refactored away.

[mattflo]

Resolves #1873.

During unzip based deployments of new releases, old files are not removed and node's require loads the old file instead of all the new ones in the new directory. The newly restored files in this commit act as a delegate for all other dependent scripts. They simply load all the new files from the new directory by using the trailing slash to disambiguate.

[ErisDS]

It's ugly, but it seems like a pretty reasonable fix for what is otherwise going to cause people a lot of pain. We're really hoping to have an update tool really soon, which would negate the need for this in future - i.e. we don't have to keep these files, and any others like it, forever and ever, which makes me feel slightly better.

[jgable]

👍 ⛵

Better than deleting the whole core directory.

[mattflo]

There... newlines and got my snafu'd submodule straightened out.

[ErisDS]

@mattflo If you have a second can you please address the commit message? It doesn't meet the contributing guidelines - the issue number should be on a newline. Thanks 👍

[mattflo]

I think that meets guidelines now.

[ErisDS]

Being honest, this PR really isn't sitting comfortably with me. It seems like a dirty solution, and that automatically makes me cautious.

However, I am struggling to come up with a reason or way which it could do anything bad. All it does is add extra files and bytes to the codebase that aren't necessarily required, but that have the potential to reduce a lot of frustration for our users.
The only objective downsides are the additional files/bytes, potential tiny decrease in performance / increase in memory usage but I'm pretty sure we're talking negligible amounts.

On the flip-side, it occurs to me that this approach as part of a 2-stage approach to removing the files. If we replace the files with these stubs this one time, we can then remove them in future. Anyone who uses a merge instead of a replace to upgrade in future will keep the stubs, rather than the old code, and anyone who uses a replace will no longer have the files.

It's less than ideal, but in future as we add an actual upgrade tool and more to Ghost, we can eventually ensure all files like this are properly cleaned up, whilst ensuring that upgrades are always successful in the short-term.

Sorry for the wall of text, this is just me documenting my thinking process.

[ErisDS]

After a long discussion in IRC, I am certain that this is the correct solution for 0.4.

However @hswolff made the following suggestions:

1. the paths that these shim files link to should probably be absolute so './api/index.js' rather than './api/'
2. each files should have a comment at the top explaining why it is there and linking to the issue so that we don't get lots of people opening PRs thinking they are a mistake / misunderstanding about node.

[ErisDS]

@mattflo Thanks for sticking with us on this and continuing to update this PR, much appreciated 👍

[mattflo]

@ErisDS, No worries. Glad to get my feet wet. It was easy enough to commit --amend and force push to my fork. ;) I hope to get more involved. Keep up the great work.