tsconfig.base.json paths completely overrides the paths of the tsconfig of functions

[Tschonti]

This might be intended, but I'm just wondering why do the base tsconfig paths completely override the paths in the functions tsconfig? Isn't the derived config supposed to be more specific? In prepare-build.ts, couldn't the reduce in line 18 start from the paths of the functions tsconfig, and then add the paths from the base config?

I managed solve my issue without this, but basically I needed to reference the same paths differently in two packages inside the monorepo, so I couldn't set those paths in the base tsconfig, I had to set it in the derived tsconfigs. But that didn't work with azure functions, because the paths in the base tsconfig was empty, so during build it replaced the paths in functions config with an empty object as well.

[AlexPshul]

Hmmm that's an interesting suggestion. The idea behind the override is pretty simple:

• The function start execution MUST be performed from the directory of the function. (func cli limitation)
• We need the paths to be up-to-date with the base tsconfig, so we need to copy and alter the pathes.

With that being said, it can do this in a smarter way and override only the paths that are part of your project. Would that make more sense?

[Tschonti]

I don't follow you exactly, It's possible that I misunderstood how this package works. I solved my problem without this, but if you think this would improve it, it's okay with me.

[AlexPshul]

Do you mind sharing how did you solve your problem? I might use it to include in the next release of the package. Also, you are more than welcome to submit a PR. :)

[Tschonti]

I ended up setting the paths in tsconfig.base.json the way the azure functions project required it, and inside packages/client/tsconfig.json the way the client package (a vite react app) required it, which overrode the base tsconfig correctly.

[lucasbmeister]

Hello,

I'm currently testing with webpack and running func start from the outDir folder. It's fine as long you don't mind losing HMR for now. This also improves the bundle size as I reduced mine from 12MB to 3MB.

I will also take a look a this package: https://github.com/beyerleinf/esbuild-azure-functions as it is currently looking like a faster alternative to webpack. Implementing this, we could add a "pack" executor for CI pipelines that use zip SAS URLs on the WEBSITE_RUN_FROM_PACKAGE.

Another point is that I like the paths centralized on the base config, however the build executor force us to have a tsconfig.build in the function folder. Ideally this should be configurable, allowing the developer to specify a custom tsconfig and error out when there's no config. I imagine this ends up solving @Tschonti problem aswell.

Ex.:

 "build": {
      "executor": "@nxazure/func:build",
      "options": {
        "tsConfig": "functions/core/monitor-integracao/tsconfig.lib.json",
        "outputPath": "dist/functions/core/monitor-integracao"
      }
    },

I'll try to hack something together for testing and open a draft PR. PS.: I'll probably give it shot a solving this too: https://github.com/AlexPshul/nxazure/issues/10

[AlexPshul]

Thanks for the suggestions @lucasbmeister and sorry it took me a while to get back to it. Summer is a bit busy. :)

Those are great ideas and adding different pack options could be amazing! Let me know if you need any help from my side, I should have a little bit more time now.

Also, if it solves #10 while we're at it, even better! 😁

[lucasbmeister]

Hi @AlexPshul, I'm currently on vacation but we'll get back into this as soon as I get back.

[AlexPshul]

Took me a while 😅 but it's fixed now in the latest release (v1.1.1). If you add your own paths on the app level, they will not be overridden (unless it's the same key as the parent tsconfig)