Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JSII does not respect lib/target specified in custom tsconfig #4706

Closed
1 task
hakenmt opened this issue Nov 19, 2024 · 4 comments · Fixed by aws/jsii-compiler#1576
Closed
1 task

JSII does not respect lib/target specified in custom tsconfig #4706

hakenmt opened this issue Nov 19, 2024 · 4 comments · Fixed by aws/jsii-compiler#1576
Labels
bug This issue is a bug. p1

Comments

@hakenmt
Copy link

hakenmt commented Nov 19, 2024

Describe the bug

JSII appears to be defaulting to es2020 and even specifying a different value in a custom tsconfig still produces an error.

Regression Issue

  • Select this option if this issue appears to be a regression.

Expected Behavior

The specified version is used to compile the library.

Current Behavior

👾 build » compile | jsii --project tsconfig.jsii.json --tsconfig tsconfig.jsii.json --silence-warnings=reserved-word
[2024-11-19T17:20:10.544] [ERROR] jsii/compiler - Compilation errors prevented the JSII assembly from being created
src/LambdaLogParser.ts:178:31 - error TS2550: Property 'replaceAll' does not exist on type 'string'. Do you need to change your target library? Try changing the 'lib' compiler option to 'es2021' or later.

178 let val: string = value.replaceAll("/", "-");
~~~~~~~~~~
👾 Task "build » compile" failed when executing "jsii --project tsconfig.jsii.json --tsconfig tsconfig.jsii.json --silence-warnings=reserved-word" (cwd: /Users/mhaken/source/alb-access-log-parsing)

Reproduction Steps

{
  "compilerOptions": {
    "outDir": "lib",
    "rootDir": "src",
    "esModuleInterop": true,
    "declarationMap": false,
    "inlineSourceMap": true,
    "inlineSources": true,
    "alwaysStrict": true,
    "declaration": true,
    "experimentalDecorators": true,
    "incremental": true,
    "lib": [
      "es2022"
    ],
    "module": "commonjs",
    "noEmitOnError": true,
    "noFallthroughCasesInSwitch": true,
    "noImplicitAny": true,
    "noImplicitReturns": true,
    "noImplicitThis": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "resolveJsonModule": true,
    "skipLibCheck": true,
    "strict": true,
    "strictNullChecks": true,
    "strictPropertyInitialization": true,
    "stripInternal": false,
    "target": "es2022",
    "composite": false,
    "tsBuildInfoFile": "lib/tsconfig.tsbuildinfo"
  },
  "include": [
    "src/**/*.ts"
  ],
  "exclude": [
    "node_modules",
    "lib/.types-compat"
  ]
}

I've added this to my .projenrc.ts

project.tasks.tryFind("compile")?.updateStep(0, { exec: "jsii --project tsconfig.jsii.json --tsconfig tsconfig.jsii.json --silence-warnings=reserved-word" })

However, I still get the error.

Possible Solution

No response

Additional Information/Context

No response

SDK version used

5.5.0

Environment details (OS name and version, etc.)

darwin

@hakenmt hakenmt added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Nov 19, 2024
@minzdrav
Copy link

Hi @hakenmt
I have exactly the same issue with jsii and ts target and I can't use string.replaceAll.
I found a temporary workaround, I hope it will help you too. I'm using polifill for this function: https://www.npmjs.com/package/ts-replace-all

@rix0rrr rix0rrr added p1 and removed needs-triage This issue or PR still needs to be triaged. labels Dec 2, 2024
@rix0rrr
Copy link
Contributor

rix0rrr commented Dec 13, 2024

Can confirm. The strange thing is, when I print the options we're passing to the compiler host it works:

    buildOnce() {
        // ....
        const tsconf = this.tsconfig;
        console.log(tsconf.compilerOptions);   // <------------
        const prog = ts.createIncrementalProgram({
            options: tsconf.compilerOptions,
            // ...
        });
    }

Output:

{
  outDir: '/Users/huijbers/Temp/testjsii/lib',
  rootDir: '/Users/huijbers/Temp/testjsii/src',
  esModuleInterop: true,
  declarationMap: false,
  inlineSourceMap: true,
  inlineSources: true,
  alwaysStrict: true,
  declaration: true,
  experimentalDecorators: true,
  incremental: true,
  lib: [ 'lib.es2022.d.ts' ],   // <--- correct
  module: 1,
  noEmitOnError: true,
  noFallthroughCasesInSwitch: true,
  noImplicitAny: true,
  noImplicitReturns: true,
  noImplicitThis: true,
  noUnusedLocals: true,
  noUnusedParameters: true,
  resolveJsonModule: true,
  skipLibCheck: true,
  strict: true,
  strictNullChecks: true,
  strictPropertyInitialization: true,
  stripInternal: false,
  target: 9,         // <---- ES2022
  composite: false,
  tsBuildInfoFile: '/Users/huijbers/Temp/testjsii/lib/tsconfig.tsbuildinfo'
}

And yet:

src/bla.ts:2:20 - error TS2550: Property 'replaceAll' does not exist on type '"haaaa"'. Do you need to change your target library? Try changing the 'lib' compiler option to 'es2021' or later.

And also:

$ npx tsc -p tsconfig.jsii.json
(all good)

I have no idea what's going on...

$ npx tsc --version
Version 5.7.2
$ npx jsii --version
5.7.1 (build ac1ec2e), typescript 5.7.2

@rix0rrr
Copy link
Contributor

rix0rrr commented Dec 13, 2024

Oh no. I found it. We're being silly.

github-merge-queue bot pushed a commit to aws/jsii-compiler that referenced this issue Dec 13, 2024
When a user provides a custom `tsconfig.json` file, they have the
ability to override the `lib` setting, which provides a number of
libraries that should be loaded at compile time.

This config setting is not passed directly into the TypeScript compiler.
Instead, it is resolved and translated into a list of `.d.ts` file that
are passed as `rootNames` to the compiler, along with the actual source
files.

In that resolution, we failed to look at the `lib` setting the user
provided, and instead always used the default config.

Fix by looking at the user-provided config, falling back to the default
config only if the user config doesn't have a `lib` setting (mirroring
the behavior of tsc).

Fixes aws/jsii#4706.

---

By submitting this pull request, I confirm that my contribution is made
under the terms of the [Apache 2.0 license].

[Apache 2.0 license]: https://www.apache.org/licenses/LICENSE-2.0
Copy link
Contributor

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.

aws-cdk-automation pushed a commit to aws/jsii-compiler that referenced this issue Dec 13, 2024
When a user provides a custom `tsconfig.json` file, they have the
ability to override the `lib` setting, which provides a number of
libraries that should be loaded at compile time.

This config setting is not passed directly into the TypeScript compiler.
Instead, it is resolved and translated into a list of `.d.ts` file that
are passed as `rootNames` to the compiler, along with the actual source
files.

In that resolution, we failed to look at the `lib` setting the user
provided, and instead always used the default config.

Fix by looking at the user-provided config, falling back to the default
config only if the user config doesn't have a `lib` setting (mirroring
the behavior of tsc).

Fixes aws/jsii#4706.

---

By submitting this pull request, I confirm that my contribution is made
under the terms of the [Apache 2.0 license].

[Apache 2.0 license]: https://www.apache.org/licenses/LICENSE-2.0

(cherry picked from commit 26a3d96)
aws-cdk-automation pushed a commit to aws/jsii-compiler that referenced this issue Dec 13, 2024
When a user provides a custom `tsconfig.json` file, they have the
ability to override the `lib` setting, which provides a number of
libraries that should be loaded at compile time.

This config setting is not passed directly into the TypeScript compiler.
Instead, it is resolved and translated into a list of `.d.ts` file that
are passed as `rootNames` to the compiler, along with the actual source
files.

In that resolution, we failed to look at the `lib` setting the user
provided, and instead always used the default config.

Fix by looking at the user-provided config, falling back to the default
config only if the user config doesn't have a `lib` setting (mirroring
the behavior of tsc).

Fixes aws/jsii#4706.

---

By submitting this pull request, I confirm that my contribution is made
under the terms of the [Apache 2.0 license].

[Apache 2.0 license]: https://www.apache.org/licenses/LICENSE-2.0

(cherry picked from commit 26a3d96)
aws-cdk-automation pushed a commit to aws/jsii-compiler that referenced this issue Dec 13, 2024
When a user provides a custom `tsconfig.json` file, they have the
ability to override the `lib` setting, which provides a number of
libraries that should be loaded at compile time.

This config setting is not passed directly into the TypeScript compiler.
Instead, it is resolved and translated into a list of `.d.ts` file that
are passed as `rootNames` to the compiler, along with the actual source
files.

In that resolution, we failed to look at the `lib` setting the user
provided, and instead always used the default config.

Fix by looking at the user-provided config, falling back to the default
config only if the user config doesn't have a `lib` setting (mirroring
the behavior of tsc).

Fixes aws/jsii#4706.

---

By submitting this pull request, I confirm that my contribution is made
under the terms of the [Apache 2.0 license].

[Apache 2.0 license]: https://www.apache.org/licenses/LICENSE-2.0

(cherry picked from commit 26a3d96)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue is a bug. p1
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants