Allow ng build to put files in the outdir and levels higher than the outdir

[johnpapa]

Bug Report or Feature Request (mark with an x)

- [ x ] bug report -> please search issues before submitting
- [ ] feature request

Versions.

@angular/cli: 1.4.4+
node: 6.11.4
os: darwin x64

Repro steps.

See the project here https://github.com/Azure-Samples/angular-cosmosdb/tree/develop in the develop branch.

Notice that I set the outdir and root like this

      "root": "src/client",
      "outDir": "dist/publicweb",

Now notice I have assets that I want to end up in the folder one level higher than the outdir.

"assets": [
        {
          "glob": "**/*.*",
          "input": "../server/",
          "output": "../"
        },
      ],

When i run this I get an error saying I can't do this. This started in 1.4.4. It works in 1.4.3

Desired functionality.

I would like this to work so I can deploy both an express server from src/server/** and the client app , ending up in the outdir, where the node/express server serves everything in a folder below it. See below:

/dist/index.js // my express server
/dist/publicweb // the folder with my angular client code

Mention any other details that might be useful.

I had a chat with @Brocco about this at AngularMix ... I'm hoping we can find a way to do this where it is allowed to go up the outdir as long as it doesn't go past the project root.

[hansl]

This is done so that people don't overwrite their app by mistake (or a malicious app overwrites system files). I'm not sure what the proper way to fix it. Preventing mistakes is relative easy; have a flag that the user needs to specify to true. Preventing malicious apps from outputting your .bashrc while allowing people to put files outside your output dir is more difficult.

I'll think about a proper solution and come to it.

The PR that added this check is #7778

[filipesilva]

@hansl I think a good compromise is a flag on the asset definition:

"assets": [
        {
          "glob": "**/*.*",
          "input": "../server/",
          "output": "../",
          "disablePathCheck": true
        },
      ],

WDYT?

[elvisbegovic]

7days ago I asked it here #7773 (comment)

"disablePathCheck": true seems easy but i will never find this option quickly so don't forget improve this error message

"An asset cannot be written to a location outside of the output path. If you know what you're doing add "disablePathCheck": true in assets[] of your config file."

[hansl]

So two points:

1. I will not disable all checks. It would be disastrous to disable writing outside your project.
2. I agree that whatever we choose we need to make the error message easy for the user to follow.

[johnpapa]

I agree on #1. There should be a check.

Perhaps there is a way to allow going up the chain by writing logic that checks that the output does not have more dots up the chain than the the outDir has slashes.

"assets": [
      "outDir": "dist/publicweb",
        {
          "glob": "**/*.*",
          "input": "../server/",
          "output": "../",
        },
      ],

[clydin]

Something to consider as well is that the use cases shown so far (universal, multi-apps, and translations) are all really dealing with deployment staging rather than app asset copying. The CLI doesn’t currently have a method to handle the post-build staging step so the asset configuration is being novelly used/abused to provide the functionality.
Deployment staging can be achieved currently with shell/npm scripts. However, as universal and multi-language apps become more common due to the prerequisite tools becoming more stable, a more integrated staging feature set could be every useful moving forward.

[hansl]

Deployment is an entirely separate story though. I agree we need a proper solution for deployment, but it requires design and planning. This is good enough for most people in the meantime.

As far as option goes, I'll try to keep a positive option instead of double negative (allow or enable instead of disable).

[hansl]

What do you think of allowOutsideOutDir?

[johnpapa]

that works.

I agree deployment is different than a build. But a build helps put things in the right place, so we can run them locally how we wish. I do think the CLI is a valid place to do simple copy logic like this ... once it goes beyond copying, it should be a separate thing IMO.

I'm feeling this out ... trying not to introduce yet another thing into the process. I can show you sometime if that helps.