imports not working in typescript project

[oakgary]

/file_a.ts

export async function test() {
  console.log('test');
}

/file_b.ts

import { test } from './file_a.ts';
export async function handler(event: LambdaEvent): Promise<LambdaResponse> {
  await test();
}

Executing the handler of file_b (using sls offline or deploying to aws) leads to something like:

TypeError: file_a_1.test is not a function

Both eslint and typescript are not showing any errors. The code is compiling fine.
I assume it has something to do with webpack or babel.

That is the issue I am facing right now in a nutshell.
I will try to create a small repo to reproduce this error.

[oakgary]

you can find the repo here: https://github.com/oakgary/serverless-bundle-import-issue

steps to reproduce:

1. run the start script of services/my_service/package.json
2. run the local.js file

[jponc]

I'm having the exact same issue..

[jponc]

Hey mate @oakgary , try using sourcemaps: false seems to work for me

[oakgary]

@jponc Thanks for the reply. Will give it another try once someone looked deeper into this. I had to switch back my typescript-services to serverless-webpack for now, as I needed a stable version for production.

[jayair]

@oakgary Thanks for putting together the repo. I'll have a look.

[jayair]

I figured out the problem with the repo. It has to do with the location of the tsconfig.json. It's placed outside the root of the service. If it is moved to services/my_service/tsconfig.json, it works fine.

You can see it here https://github.com/oakgary/serverless-bundle-import-issue/pull/1/files

@jponc Are you doing something similar too?

[jponc]

Yes, in my case it's placed outside the root of the service.

I need this kind of configuration because I'm running on a monorepo setup with a single tsconfig for all services

[oakgary]

just gave it another shot
putting the tsconfig on service lvl did not fix the problem for me
neither did setting sourceMap to false in the tsconfig.json which i tried because i misread jponc's comment

setting sourcemaps: false (custom:bundle:sourcemaps:false) in the serverless.yml of the affected service did fix the problem for me

[jponc]

@jayair Did you manage to figure it out? I can also take a look, but yeah I think it's pretty common to have a shared tsconfig.json especially when dealing with monorepo setup

[jayair]

Getting back to this. @oakgary Did my PR not work for you? Because it worked for me.

If it is because of the location of the tsconfig.json, we need to figure out how to fix it.

[oakgary]

no, if i remember correctly it did not solve the problem for me

putting the tsconfig on service lvl did not fix the problem for me

but i am not sure anymore if i used exactly your tsconfig.json or if i adjusted my own

nevertheless i have been using serverless-bundle for the last 2-3 weeks with typescript in production now using the hotfix @jponc provided which is setting the sourcemaps value to false
i am sure thats a good entry point to investigate the problem

[jayair]

Yeah I'm digging into this issue now. It seems related to the babel loader that we are running .ts files through.

[ggrantrowberry]

I had the same issue but setting sourcemaps:false as @jponc suggested fixed it for me.

[jondot]

same issue, sourcemaps: false fixes it

[grevolution]

spent whole day figuring out why its not working and stumbled upon this. sourcemaps: false fixed it for me too. Is this going to be fixed properly?

[jayair]

I've been spending some time on this one. I think I've got a sense for what is going on. Are you all using

"module": "commonjs"

in your tsconfig.json? Can you try removing it or using ES6?

@grevolution @jondot @ggrantrowberry @oakgary @jponc

[andrey-k]

@jayair I have the same problem. sourcemaps: false fixed the issue but I would like to have source map enabled. We use "module": "commonjs" and removing it or using ES6 didn't help

[jayair]

@andrey-k Can you also set this in your serverless.yml and try again?

custom:
  bundle:
    caching: false

[andrey-k]

@jayair caching: false didn't solve the issue. with sourcemaps: true it still fails to import local files. I use

node: v12.14.1

sls -v
Framework Core: 2.4.0
Plugin: 4.0.4
SDK: 2.3.2
Components: 3.2.1

typescript: 4.0.3

Do you need any additional information?

[jayair]

@andrey-k I might need a sample repo from you.

I tried @oakgary's repo (https://github.com/oakgary/serverless-bundle-import-issue) with the following steps and it worked.

$ git clone https://github.com/oakgary/serverless-bundle-import-issue.git
$ yarn
# Remove "module": "commonjs" from tsconfig.json
$ cd services/my_service
$ serverless invoke local -f myLambda

[andrey-k]

@jayair actually a combination of caching: false and removal of "module": "commonjs" from tsconfig.json worked. Also, it works if I set "module": "es6" with caching: false

[jayair]

Yeah the issue is that with commonjs set, the exports conflict with the export set by the babel-plugin-source-map-support plugin. You shouldn't have to set it to commonjs in your tsconfig.json with serverless-bundle because we transpile it through Babel and ensure that the exports are set correctly.

If some of the other folks in this thread can confirm, then I'll document this issue and possibly add a warning if commonjs is set.

[jayair]

@andrey-k Btw, you can remove the caching flag. That was just to ensure that while you were changing these options, you weren't still using the cached build.

[jayair]

I should also mention this for anybody testing the commonjs option, the best way to ensure that the results are not cached is not remove your node_modules directory and try again.

[jponc]

Yeah I might give this a try tonight. Btw if some of you guys are wondering why it's failing, the default tsconfig module is set to commonjs when you specify target: es3 (default) or es5. So maybe change that to es6 so it picks module: es6

[jayair]

If folks can confirm that the above solves their issue, we can either document this or add a check while building.

[Namstel]

If folks can confirm that the above solves their issue, we can either document this or add a check while building.

I can confirm that removing "module": "commonjs", from tsconfig.json fixed the issue. Thanks @jayair .

[Luke-Rhodes-RDSLE7]

For me the removal of "commonjs" wasn't an option.

It seems to be common to set the libraryTarget webpack config to "umd" to resolve this issue when not using serverless-bundle.

this.webpackConfig.output.libraryTarget = 'umd' on line 158 of validate.js does the trick.

For reference: serverless-heaven/serverless-webpack#23

[jayair]

@Luke-Rhodes-RDSLE4 How come removing commonjs isn't an option for your case?

[jayair]

Pushed a new release that shows a warning if commonjs is detected. Also added a note to the README.

https://github.com/AnomalyInnovations/serverless-bundle/releases/tag/v4.0.0

https://github.com/AnomalyInnovations/serverless-bundle#module-and-targets

[jayair]

Just pushed a patch to handle non standard JSON tsconfigs.

https://github.com/AnomalyInnovations/serverless-bundle/releases/tag/v4.0.1

[pgrzesik]

Hello @jayair 👋 Is there a reason why there's a warning emitted instead of throwing an error? Does it still work with warning or user can expect "bad things" to happen at a later point in time? If the second case is expected, maybe it should unconditionally throw there?