Could you provide more context for this PR? We look for the sourceRoot as a parameter provided in configuration, and place the sandboxes.ts file there by design. Therefore, if you specify your sourceRoot as something other than ./src, that is where the sandboxes.ts file will be placed.

It seems more intuitive for sandboxes.ts to be placed at the sourceRoot instead of the project root, since its function is to export the sandboxes from your application's components, which would also live in sourceRoot.

So here's the deal. Take a look at this line of code here:
https://github.com/SoCreate/angular-playground/blob/master/src/app/load-sandboxes.ts#L5
. This is how the sandboxes file is loaded into angular playground.
Following the node module resolution algorithm won't find where the
sandboxes.ts file was stored so now webpack will search in places that the
angular cli has configured it to look (namely the root directory and
./src). If you project root is not ./src then webpack will fail to find the
sandboxes.ts file. Thus angular playground currently has an implicit requirement that users with non-default
directory structures must run ng eject and manage their own webpack config which is non-ideal.
My solution to this problem was to place the sandboxes.ts file at the root
of the project so that it could be located regardless of what directory
structure the project has.

Thanks for describing the problem in more detail. Can you give an example of such a non-standard directory structure? We use Playground internally with a multiple-app structure, e.g. src/app1/app, src/app2/app. Each of these "sub-apps" is outfitted with its own Playground that is configured within a single .angular-cli.json.

As long as the .angular-cli.json root property is consistent between your application and the playground application, I don't see why sandboxes.ts wouldn't resolve properly. For instance, if your non-standard directory root is somepath/other, make sure that both entries in .angular-cli.json have "root": "somepath/other".

Thanks for putting that together. I'm going to spend some time looking into this issue--the latest CLI update has caused some problems with multi-app architectures. I've created a ticket on their repo that addresses one such problem, although the error you sent is new to me.

So I've done a lot of investigation into this issue and I thought I'd provide some findings.

Angular CLI 1.5 update introduces a more strict adherence to the tsconfig.json, according to their release post. Playground uses a project's existing CLI configuration to compile sandbox chunks from the sandboxes.ts file. Therefore, it stands that the increased strictness of tsconfig.json settings along with the issue that I referenced above have led to some issues when using Playground with non-default structures.

I am investigating other solutions to this problem that don't involve moving the sandboxes.ts path. I tested it on some other application structures and it didn't resolve the error in all cases.

Yeah that is certainly a consideration. That would require modifying the node_modules output at runtime though, since the sandboxes are resolved by webpack before it hits the angular application.

@mrmeku I've got a PR out that should resolve this issue, #75. I decided not to do use this approach since the latest CLI version (1.6.2) introduced some changes to the webpack configuration that altered the way Playground was chunking out each sandbox individually. #75 fixes both issues.