refactor: remove hand-written index files

[bajtos]

1. The first commit moves if (require.main === module) code from /index.js to src/index.ts. This is a preparation to allow us to remove /index.js file entirely. It leaves the repository in a broken state, but that's fine because the next commit fixes the problem and will be squashed into this one before landing.

   This change has a nice benefit that it enables TypeScript compiler checks for the code building app config, it discovered a possible problem in +process.env.PORT line (+undefined returns NaN).

   I am also slightly changing exports to improve ergonomics - the type ApplicationOptions is exported together with the main application class, so that consumers don't need to import the options from @loopback/context.

2. In the next step, I am committing the outcome of running an automated script (see https://gist.github.com/bajtos/68672a8229bd03fddad5a4ad1442061f) to remove top-level index files and update package.json metadata.

3. In the third commit I am updating project templates in packages/cli to match the new style.

4. Finally I am updating documentation, tutorials and README files in example/*.

Resolves #2613, resolves #2609

Verification

Here are the steps I performed to verify that this change does not break our source-code editing experience in VS Code:

1. Run npm run clean to remove all dist folders

2. Verify that VSCode is still able to understand relations between source code artifacts defined in one package (e.g. context) and used elsewhere (e.g. example-todo), as described in https://github.com/strongloop/loopback-next/blob/master/docs/site/VSCODE.md:

   • Verify that "Go to definition" works across package boundaries. Find a place
     where we are calling @inject in authentication package, press F12 to go to
     the definition of inject. VSCode should jump to the .ts file in src (as
     opposed to jumping to a .d.ts file in dist)
   • Verify that refactorings like "rename symbol" (F2) will change all places
     using the renamed entity. Two different scenarios to verify: rename at the place
     where the entity is defined, rename at the place where the entity is used. (You
     can e.g. rename inject to test.)

Checklist

👉 Read and sign the CLA (Contributor License Agreement) 👈

• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• API Documentation in code was updated
• Documentation in /docs/site was updated
• Affected artifact templates in packages/cli were updated
• Affected example projects in examples/* were updated

👉 Check out how to submit a PR 👈

[agnes512]

👍

Here are the steps I performed to verify that this change does not break our source-code editing experience in VS Code

[raymondfeng]

I tried on VScode. It seems to be working.

[raymondfeng]

@bajtos Please investigate why CI is failing.

[bajtos]

To be done: update documentation, tutorials and README files in example/*.

Done in 834d6cd. I searched for all occurrences of the string index.js in *.md files to locate places needed an update.

[bajtos]

Please investigate why CI is failing.

These failures are weird, I am not able to reproduce them in my working copy. I had to follow up the exact steps performed by Travis CI (starting from git init and git remote add) to get the build to fail locally (albeit with a slightly different message from Prettier).

2e32364 is fixing the problem.

Strangely enough, after fixing Mocha failures, I see linting errors now, in code that seem to be unrelated to my changes 😠

[bajtos]

Possibly related: typescript-eslint/typescript-eslint#1573

[bajtos]

Strangely enough, after fixing Mocha failures, I see linting errors now, in code that seem to be unrelated to my changes

I think this problem is caused by our code-lint script that runs eslint on the bare repository (without running tsc to build dist files first).

[bajtos]

I tried to configure eslint to be aware of TypeScript Project References (see 07b499e), but that did not solve the problem :(

See also https://github.com/typescript-eslint/typescript-eslint/blob/795fd1c529ee58e97283c9ddf8463703517b50ab/packages/parser/README.md#parseroptionsproject

[bajtos]

@raymondfeng I added three new commits, PTAL:

• 834d6cd update docs
• 2e32364 fix yarn test failing on prettier
• b88c3d9 compile the code before running eslint on Travis CI

I am not very happy about b88c3d9, but then it's affecting only one of the parallel jobs on CI, so it shouldn't make things any worse.

I have some ideas how to improve our eslint setup so that the build step is hopefully not needed, but I prefer to leave them out of scope of this pull request and explore them after this PR is landed.

[bajtos]

coverage/coveralls — Coverage decreased (-0.5%) to 91.666%

This is caused by the fact that our tests are not executing main functions in src/index.ts. I am surprised they were not detected by nyc/coveralls before my change, while the code was living in index.js files 🤷‍♂️